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@ Method and system for aggregating objects. 

@ A method and system for aggregating objects 
within a computer system are pfY}vided. In a 
preferred emisodiment. the method aggregates 
an enclosed object within an enclosing object. 
The enclosed object has an object nnanagement 
interface and an external interface, while the 
enclosing object has a control ling object man- 
agement interface. The controlling object man- 
agement interface and the external interface of 
the enclosed object have query function menv 
bers for receiving an identifier of an interface 
and for returning a reference to the identified 
interface. A preferred embodiment creates an 
instance of an enclosing object and an object to 
be enclosed. In static aggregation, the control- 
ling object management Interface of the enclos- 
ing object knows in advance how to return an 
identifier to the external interface of the en- 
closed object In dynamic aggregation, an 
object to be enclosed is added to the enclosing 
object after the enclosing object is instantiated. 
Once aggregated, when the query function 
member of the object management interface of 
the enclosed object receives an identifier of an 
interface, it invokes the query function member 
of the controlling object management interface 
forwarding the interface identifier and returns 
the reference to an interface returned by the 
invoked query function member of the control- 
ling object management interface. In dynamic 
aggregation, rules for determining to which 
Interface to return a reference can by added to 
the enclosing object and used by the query 
function member of the controlling object man- 
agement interface. 
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Cross- Reference to Related Application 

This application Is a continuation in part for U.S. Patent Application Serial No. 07/996,552, entitled "A Meth- 
od and System for Aggregating Objects," which was filed on December 24, 1992. and which is hereby incor- 
5 porated by reference. 

Technical Field 

This invention relates generally to a computer method and system of implementing interfaces to objects 
10 and, more specifically, to a method and system for aggregating objects. 

Background of the Invention 

As computer software systems Increase in sophistication, the cost of developing the software increases. 
15 To minimize the cost of software development, developers often share code. Prior development efforts use 
three types of code sharing: (1) source code sharing, (2) compiled code sharing, and (3) code sharing through 
inheritance. 

Also, as computer software systems increase in sophistication, software users are faced with increasing 
complexity in the maintenance and extensibility of their computer systenrts. Each time a software vendor gen- 
20 erates new or improved capabilities, a user who wishes to benefit must somehow incorporate these modifica- 
tions. Prior systems generally require such a user to upgrade the software, forcing the user to reinstall at least 
part of the system. Or, prior systems require a software developer to plan in advance for future enhancements 
and Install the necessary hooks in the original system to enable the loading of enhancements at some future 
time. 

25 Moreover, if a user wishes to enhance the capabilities of a piece of currently owned software by adding 

capabilities produced by a different software vendor, the user is limited by what the software vendors planned 
in advance. Prior systems generally require that the two pieces of software be designed to work together and 
that at least one of the software pieces have knowledge of what capabilities the other provides. Thus, in prior 
systems, later modifications to code as well as the sharing of code must be accounted for in the software de- 

30 sign. 

Source and compiled code sharing have been widely used for many years. Source code sharing refers to 
the use of the same source code by vartous computer programs or by various versions of the same computer 
program. For example, a spreadsheet program typically includes source code to control the displaying of a 
spreadsheet. If a word processing program allows the embedding of a spreadsheet within a document, then 

35 the word processing program may use the same (or slightly modified) source code to display the embedded 
spreadsheet object Source code sharing is typically used by a single developer who develops multiple com- 
puter programs. For competitive reasons, developers typically do not share their source code with other de- 
velopers. Moreover, even if the developer does share source code, the recipient of source code typically modi- 
fies the source code and thus two versions of the source code are maintained. 

40 Compiled code sharing refers to the use of the same compiled code by various computer progranis. The 

complied code Is typically stored In a static or dynamic link library. Compiled code stored In a static link library 
is shared when a computer program is linked before execution. Compiled code stored In a dynamic link library 
is shared when a computer program is linked during execution. The developer of a spell checking program, for 
example, may share compiled code by compiling the program and storing the compiled code in a static link 

46 library. The static link library can then be distributed to developers of word processing programs who can link 
the compiled spell checking code into their word processing program. The developer of the spell checking pro- 
gram typically needs to modify the compiled code to meet special requirements of certain developers. These 
modifications tend to increase the complexity (and size) of the compiled code and may conflict with require- 
ments of other recipients. Alternatively, the developer could distribute multiple versions of the static link library. 

50 However, the maintenance of multiple versions can be costly. 

Object-oriented programming techniques employ a concept referred to as Inheritance to allow the sharing 
of code. An overview of well-known object-oriented programming techniques Is provided, since the present in- 
vention is described below using object-oriented programming. Two common characteristics of object-oriented 
programming languages are support for data encapsulation and data type inheritance. Data encapsulation re- 

55 fers to the binding of functions and data. Inheritance refers to the ability to declare a data type in temrvs of other 
data types. 

In the C^-t- language, object-oriented techniques are supported through the use of classes. A class is a 
user-defined type. A class declaratksn describes the data members and function members of the class. For 
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example, the following declaration defines data members and a function member of a dass named CIRCLE. 

class CIRCLE 
{ public: 

int X, y; 

int radius; 

10 void drawQ; 

}; 

Variables x and y specify the center location of a circle and variable radius specifies the radius of the circle. 
15 These variables are referred to as data members of the class CIRCLE. The function draw is a user-defined 
function that draws the circle of the specified radius at the specified location. The function draw is referred to 
as a function member of class CIRCLE. The data members and function members of a dass are bound together 
in that the function operates on an instance of the class. An instance of a class is also called an object of the 
class. 

20 In the syntax of C++, the following statement declares the objects a and b to be of type class CIRCLE. 

CIRCLE a, b; 

This declaration causes the allocation of memory for the objects a and b. The following statements assign data 
to the data members of objects a and b. 
a.x = 2; 
25 a.y = 2; 

a. radius = 1; 

b. x = 4; 
b.y = 5; 
b.radius = 2; 

30 The following statements are used bo draw the cirdes defined by objects a and b. 

a. drawQ; 

b. drawQ; 

A derived class is a class that inherits the characteristics-data members and function members-of its 
base dasses. For example, the following derived class CIRCLE_FILL inherits the characteristics of the base 
35 class CIRCLE. 



class CIRCLE_FILL : CIRCLE 
{ public: 

int pattern; 
void fillO; 

}; 

This declaration specifies that class CIRCLE_FILL includes all the data and function members that are in dass 
CIRCLE in addition to those data and function members Introduced In the declaration of dass CIRCLE_FILL, 
that Is, data member pattern and function member fill. In this example, dass CIRCLE_FILL has data members 
X, y, radius, and pattern and function members draw and fill. Class CIRCLE_FILL is said to "Inherit" the char- 
acteristics of dass CIRCLE. A class that Inherits the characteristics of another dass is a derived dass (e.g., 
CIRCLE_FILL). A class that does not Inherit the characteristics of another class Is a primary (root) class (e.g., 
CIRCLE). A class whose characteristics are inherited by another dass is a base class (e.g., CIRCLE Is a base 
class of CIRCLE_FILL). A derived class may inherit the characteristics of several classes, that Is, a derived 
class may have several base classes. This Is referred to as multiple inheritance. 

A derived class may specify that a base class is to be inherited virtually. Virtual inheritance of a base dass 
means that only one Instance of the virtual base class exists In the derived class. For example, the following 
is an example of a derived class with two nonvirtual base classes, 
class CIRCLE_1 : CIRCLE {...}; 
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Class CIRCLE_2 : CIRCLE {...}; 
class PATTERN : CIRCLE_1. CIRCLE_2{...}; 
In this declaration class PATTERN Inherits dass CIRCLE twice nonvirtually through classes CIRCLE_1 and 
CIRCLE_2. There are two instances of dass CIRCLE in class PATTERN. 
5 The following is an example of a derived class with two virtual base classes, 

class CIRCLE_1 : virtual CIRCLE {...); 
class CIRCLE_2 : virtual CIRCLE {...); 
class PATTERN: CIRCLE_1. CIRCLE_2{...); 
The derived class PATTERN inherits class CIRCLE twice virtually through classes CIRCLE_1 and CIRCLE_2. 
10 Since the class CIRCLE is virtually inherited twice, there is only one object of class CIRCLE in the derived 
class PATTERN. One skilled in the art would appreciate virtual inheritance can be very useful when the dass 
derivation is more complex. 

A dass may also specify whether its function members are virtual. Declaring that a function member Is 
virtual means that the function can be overridden by a function of the same name and type in a derived class. 
15 In the following example, the function draw is dedared to be virtual in classes CIRCLE and CIRCLE_FILL. 

class CIRCLE 
{ public: 

20 

int X, y; 

int radius; 

virtual void draw(); 

25 }; 

class CIRCLE^FILL : CIRCLE 
{ public: 

int pattern; 
virtual void drawQ; 

}; 

35 

If a virtual function is declared without providing an implementation, then it is referred to as a pure virtual func- 
tion. A pure virtual function is a virtual function declared with the pure specifier, "= 0". If a class specifies a 
pure virtual function, then any derived class needs to specify an implementation for that function member be- 
fore that function member may be invoked. 

40 In order to access objects, the C++ language provides a pointer data type. A pointer holds values that are 

addresses of objects in memory. Through a pointer, an object can be referenced. The following statement de- 
clares variable c_j}tr to be a pointer on an object of type class CIRCLE and sets variable c_ptr to hold the ad- 
dress of object c. 

CIRCLE •c_ptn 

45 c_ptr = &c; 

Continuing with the example, the following statement declares object a to be of type class CIRCLE and object 
b to be of type dass CIRCLE_FILL. 

CIRCLE a; 

CIRCLE_FILLb; 

50 The following statement refers to the function draw as defined in dass CIRCLE. 

a. drawQ; 

Whereas, the following statement refers to the function draw defined in class CIRCLE_FILL. 

b. drawQ; 

Moreover, the following statements type cast object b to an object of type class CIRCLE and invoke the function 
65 draw that is defined in class CIRCLE FILL. 
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CIRCLE *c_ptr; 
c_ptr = &b; 

c_ptr->drawO; // CIRCLE_FILL::drawO 

5 

Thus, the virtual function that is called is function CIRCLE_FILL::draw. 

Figure 1 is a block diagram illustrating typical data structures used to represent an object. An object Is 
composed of instance data (data nnembers) and member functions, which implement the behavior of the object. 

10 The data structures used to represent an object comprise instance data structure 101 , virtual function table 
1 02, and the function members 1 03, 1 04, 1 05. The instance data structure 1 01 contains a pointer to the virtual 
function table 102 and contains data members. The virtual function table 102 contains an entry for each virtual 
function member defined for the objecL Each entry contains a reference to the code that implements the cor- 
responding function member. The layout of this sample object conforms to the model defined in U.S. Patent 

15 Application Serial No. 07/682,537, entitled "A Method for Implementing Virtual Functions and Virtual Bases in 
a Compilerfor an Object Oriented Programming Language," which is hereby incorporated by reference. In the 
following, an object will be described as an instance of a dass as defined by the C++ programming language. 
One skilled in the art would appreciate that objects can be defined using other programming languages. 
The inheritance of a class is a type of code sharing. Adeveloper of a class can provide the implementation 

20 Of the dass to other developers. These other developers can then create dasses that derive from the dass 
provided. Thus, the function members of the provided class are shared. If, however, a class is inherited and a 
virtual function is overridden, then the testing of the overriding virtual function can be complex. The overriding 
virtual function can nriodify the state of the object in a way that affects non-overridden functions. Thus, each 
inherited function must be independently tested in conjunction with the testing of the overriding virtual function. 

25 To ameliorate the complexities of testing, the developers of a class implementation may distribute source code 
with the implementation. Unfortunately, the distribution of source code has the same drawbacks to sharing 
source coda as discussed above. 

An advantage of using object-oriented techniques is that these techniques can be used to facilitate the 
sharing of objects. In particular, object-oriented techniques facilitate the creation of compound documents. A 

30 compound document is a document that contains objects generated by various computer programs. (Typically, 
only the data members of the object and the dass type are stored in a compound document.) For example, a 
word processing document that contains a spreadsheet object generated by a spreadsheet program is a com- 
pound document. A word processing program allows a user to embed a spreadsheet object (e.g., a cell) within 
a word processing document. To allow this embedding, the word processing program is compiled using the 

35 class definition of the object to be embedded to access function members of the embedded object. Thus, the 
word processing program would need to be compiled using the class definition of each dass of objects that 
can be embedded in a word processing document. To embed an object of a new dass into a word processing 
document, the word processing program would need to be recompiled with the new class definitkin. Thus, only 
objects of classes selected by the developer of the word processing program can be embedded. Furthernnore, 

40 new dasses can only be supported with a new release of the word processing program. 

To allow objects of an arbitrary dass to be embedded into compound documents, interfaces are defined 
through which an object can be accessed without the need for the word processing program to have access 
to the dass definitions at compile time. An abstract class Is a dass in which there Is at least one virtual function 
member with no implementation (a pure virtual function member). An interface Is an abstract class with no 

45 data members and whose virtual functions are all pure. Thus, an Interface provides a protocol for two programs 
to communicate. Interfaces are typically used for derivation: a program implements classes that provide Im- 
plementations for the Interfaces the classes are derived from. Thereafter, objects are created as instances of 
these derived classes. 

The following class definition Is an example definition of an Interface. In this example, for simplicity of ex- 
50 planation, rather than allowing any dass of object to be embedded in its documents, a word processing program 
allows spreadsheet objects to be embedded. Any spreadsheet object that provides this interface can be em- 
bedded, regardless of how the object is Implemented. Moreover, any spreadsheet object, whether Implemented 
before or after the word processing program is compiled, can be embedded. 

55 
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class ISpreadSheet 

{ virtual void File() = 0; 

5 

virtual void EditQ = 0; 
virtual void Formula() = 0; 
virtual void FormatQ = 0; 
^0 virtual void GetCell (string RC, cell *pCell) = 0; 

virtual void DataQ = 0; 

} 

15 

The developer of a spreadsheet program would need to provide an implementation of the Interface to allow 
the spreadsheet objects to be embedded in a word processing document. 

When the word processing program embeds a spreadsheet object, the program needs access to the code 
that Implements the Interface for the spreadsheet object To access the class code, each implementation is 

20 given a unique class Identifier For example, code implementing a spreadsheet object developed by Microsoft 
Corporation may have a class identifier of "MSSpreadsheet," while code implementing a spreadsheet object 
developed by another corporation may have a class identifier of "LTSSpreadsheet" A persistent registry in 
each computer system is maintained that maps each class Identifier to the code that implements the class. 
Typically, when a spreadsheet program is installed on a computer system, the persistent registry is updated 

25 to reflect the availability of that class of spreadsheet objects. So long as a spreadsheet developer implements 
each function member defined by the interface and the persistent registry is maintained, the word processing 
program can embed instances of the developer's spreadsheet objects Into a word processing document. The 
word processing program accesses the function members of the embedded spreadsheet objects without re- 
gard to who has implemented them or how they have been implemented. 

30 Various spreadsheet developers may wish, however, to implement only certain function members. For ex- 

ample, a spreadsheet developer may not want to implement database support, but may want to support all 
other function members. To allow a spreadsheet developer to support only some of the function members, 
while still allowing the objects to be embedded, multiple interfaces for spreadsheet objects are defined. For 
example, the interfaces {Database and I Basic may be defined for a spreadsheet object as follows. 

35 

class [Basic 

{ virtual void FileQ = 0; 
40 virtual void Edit() = 0; 

virtual void FormulaO = 0; 
virtual void FormatQ = 0; 

virtual void GetCell (string RC, cell ♦pCell) = 0; 



class IDatabase 
^ { virtual void Data() = 0; 

} 

Each spreadsheet developer would Implement the IBasic Interface and, optionally, the IDatabase interface. 
55 At run time, the word processing program would need to determine whether a spreadsheet object to be 

embedded supports the IDatabase Interface. To make this determination, another interface is defined (that 
every spreadsheet object Implements) with a function member that Indicates which interfaces are implemented 
for the object. This interface Is named lUnknown (and referred to as the unknown Interface or the object man- 
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agement interface) and is defined as follows. 

class lUnknown 

' { virtual HRESULT Querylnterface (REFIID iid, void ''ppv) = 0; 

virtual ULONG AddRefQ = 0; 
virtual ULONG Release 0 = 0; 

^0 } 



The lUnknown interface defines the function member (method) Querylnterface. The method Querylnterface 
is passed an interface identifier (e.g., "IDatabase") in parameter iid (of type REFIID) and returns a pointer to 
15 the implementation of the Identified interface for the object for which the method is invoked in parameter ppv. 
If the object does not support the interface, then the method returns a false. The type HRESULT indicates a 
predefined status, the type REFIID indicates a reference to an interface identifier, and the type ULONG indi- 
cates an unsigned long integer. 



20 

CodeTablg 1 



HRESULT XX;:QueryInterface(REFlID iid, void **ppv) 
25 { ret •= TRUE; 

switch (iid) { 
case IID_I Basic: 

*ppv = plBasic; 
break; 
ca<;e irDJDatabase: 

*ppv = plDatabase; 
break; 
case IED_IUnknown: 
*ppv = this; 
break; 

default: 

ret = FALSE; 

} 

if (ret = TRUE) {AddRef();) ; 
return ret; 

40 } 



Code Table 1 contains C-*-*- pseudocode for a typical implementation of the method Querylnterface for 
class XX, which inherits the class lUnknown. If the spreadsheet object supports the IDatabase interface, then 
45 the method Querylnterface includes the appropriate case label within the switch statement The variables pl- 
Basic and plDatabase point to a pointer to the virtual function tables of the I Basic and IDatabase interfaces, 
respectively. The method Querylnterface invokes to method AddRef (described below) to increment a refer- 
ence count for the object of class XX when a pointer to an Interface is returned. 

50 Code Table 2 

void XX::AddRef() {rBfcount++;} 

void XX:: Releasee {if(~refcount=0) delete this;} 

The interface lUnknown also defines the methods AddRef and Release, which are used to implement ref- 
erence counting. Whenever a new reference to an interface is created, the method AddRef is invoked to in- 
crement a reference count of the object Whenever a reference is no longer needed, the method Release is 



7 



EP 0 664 510 A2 



invoked to decrement the reference count of the object and, when the reference count goes to zero, to deal- 
locate the object. Code Table 2 contains 0++ pseudocode for a typical implenrientatlon of the methods AddRef 
and Release for class XX, which inherits the class {Unknown. 

The {Database interface and {Basic interface inherit the {Unknown interface. The following definitions il- 
5 lustrate the use of the lUnknown Interface. 



class IDatabase : public lUnknown 
{ public: 

virtual void Data() = 0; 

} 

class IBasic : public lUnknown 
{ public: 

virtual void File() = 0; 
virtual void EditQ = 0; 
virtual void Formula() = 0; 
virtual void FormatQ = 0; 
virtual void GetCell (string RC, cell *pCell) = 0; 

} 

Figure 2 is a block diagram illustrating a sample data structure of a spreadsheet object using nested class- 
so es. The spreadsheet object comprises object data structure 201 « IBasic interface data structure 203, 1 Database 
interface data structure 204, the virtual function tables 202, 205, 206 and methods 207 through 221 . The object 
data structure 201 contains a pointer to the virtual function table 202 and pointers to the IBasic and IDatabase 
interface. Each entry in the virtual function table 202 contains a pointer to a method of the lUnknown interface. 
The IBasic interface data structure 203 contains a pointer to the virtual function table 205. Each entry in the 
35 virtual function table 205 contains a pointer to a method of the IBasic interface. The IDatabase interface data 
structure 204 contains a p>ointer to the virtual function table 206. Each entry in the virtual function table 207 
contains a pointer to a method of the IDatabase interface. Since the IBasic and IDatabase interfaces inherit 
the lUnknown interface, each virtual function table 205 and 206 contains a pointer to the methods Queryln- 
terface, AddRef, and Release. In the following, an object data structure is represented by the shape 222 labeled 
40 with the interfaces through which the object may be accessed. 

The following pseudocode illustrates how a word processing program determines whether a spreadsheet 
object supports the {Database interface. 

if (pSpreadsheet->Query{nterface("{Database", &plDatabase)) 
y/ IDatabase supported 
45 else 

// {Database not supported 

The pointer pSpreadsheet is a pointer to an instance of the spreadsheet dass shown in Figure 2. (pSpreadsheet 
points to data structure 201.) If the object supports the {Database interface, the method Querylnterface de- 
fined by method 207 sets the po{nter pl Database to po{nt to the IDatabase data structure 204 and returns true 
50 as its value. 

Normally, an object can be in3tant{ated (an Instance of the object created In memory) by a variable de- 
claration or by the "new" operator. However, both techniques of Instantiation need the class definition at com- 
pile time. A different technique is needed to allow a word processing program to instantiate a spreadsheet ob- 
ject at run time. One technique provides a global function CreatelnstanceXX, which is defined in the following. 
55 static void CreatelnstanceXX (REFMD iid, void **ppv)= 0; 

The method CreateinstanceXX Instantiates an object of dass XX and returns a pointer ppv to the interface of 
the object designated by parameter iid. 
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Summary of the Invention 

It is a goal of the present invention to provide a method and system for aggregating objects. 
It is another goal of the present invention to provide a method and system for dynamically modifying object 
5 behavior. 

It is another goal of the present invention to provide a method and system for dynamically aggregating ob- 
jects. 

It is another goal of the present Invention to provide a method and system for statically aggregating objects. 

It is another goal of the present invention to provide a method and system for enclosing an object within 
10 another object while exposing an interface of the enclosed object to a client of the enclosing object. 

It is another goal of the present invention to provide a method and system for enclosing an object within 
another object after the enclosing object Is instantiated. 

It is another goal of the present invention to provide a method and system for dynamically combining ob- 
jects of different types into a single object. 
15 It is another goal of the present invention to provide a method and system for implementing an object that 

can be either enclosed within another object or not enclosed within another object without modifying the im- 
plementation of the object. 

It is another goal of the present invention to provide a method and system for implementing an aggregate 
object so that a client Is unaware that the object is an aggregate. 
20 It is another goal of the present invention to provide a method and system for enclosing objects wherein 

an enclosed object can itself be an enclosing object to an arbitrary level of enclosing. 

It is another goal of the present invention to provide a method and system for enhancing a base object's 
behavior by adding a new interface to it. 

It is another goal of the present invention to provide a method and system for enhancing a base object's 
25 apparent behavior by adding an interface to it that overrides standard behavior of the base object. 

It is another goal of the present invention to provide a method and system for supplying default functionality 
to objects by enclosing them within an enclosing object where an enclosed or enclosing object implements 
the default functionality. 

It is another goal of the present invention to provide a method and system for implementing controlling 
30 behavior over common functionality present in enclosed objects. 

It Is another goal of the present invention to provide a method and system for determining which interface 
to provide to a client when the client requests an interfiace that is Implemented by more than one enclosed 
object. 

These and other goals, which will be apparent as the invention Is more fully described below, are provided 

35 by a method and system for aggregating objects within a computer system. In a preferred embodiment, the 
method aggregates an enclosed object within an enclosing object. The enclosed object has an object man- 
agement interface and one or more external interfaces, while the enclosing object has a controlling object man- 
agement Interface. Each interface exposed to a client by the aggregate object has a query function nr^mber 
for receiving an identifier of an interface and for returning a reference to the identified interface. The query 

40 function member of the controlling object management interface of the enclosing object receives an identifier 
of an interface exposed by the enclosing object and returns a reference to the exposed interface. A preferred 
method creates an instance of the enclosed object. When, the query function member of an exposed interface 
of the enclosed object receives an identifier of an interface, it invokes the query function member of the con- 
trolling object management interface of the enclosing object passing the received identifier, and returns the 

45 reference returned by the invoked query function member of the controlling object management interface of 
the enclosing object as a reference to the identified interface. 

In a preferred embodiment of static aggregation, a query function member of an enclosed object is Imple- 
mented with knowledge of the external interfaces of the enclosed object and has no knowledge of Interfaces 
(other than the controlling object management Interface) of the enclosing object or other enclosed objects. The 

50 query function member of a controlling object management interface of the enclosing object is implemented 
with knowledge of the exposed Interfaces of enclosed objects. 

In a preferred embodiment of dynamic aggregation, an object can be modified dynamically by allowing 
interface instances, as implemented by objects, to be aggregated during the execution of a client program. 
Interfaces are aggregated by dynamically enclosing the objects that implement them into a multltype object. 

55 Each interface to be added is implemented by an object which has the ability to be aggregated. A multltype 
object is created to act as an enclosing object. The multltype object has an add interface function member, 
which can be used to aggregate interfaces by adding them to the enclosing multltype object The multltype 
object also has an add object function nr^ember for aggregating all of the interfaces of an object The multltype 
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object also has a query function member for retrieving references to the added interfaces upon request from 
a client This query function member is part of the controlling object nnanagement interface of the enclosing 
multitype object. Also, an instance of an object that implements the interface to be aggregated is created. Dur- 
ing creation, a pointer to the enclosing multitype object is passed to the object to be enclosed to enable the 

5 enclosed object to communicate with the enclosing multitype object The created object implementing the in- 
terface to be aggregated has a query function member, which supports retrieval of a reference to the interface 
to be aggregated. A preferred method invokes the add interface function member or the add object function 
member of the enclosing multitype object passing it a reference to the created object implementing the inter- 
face to be aggregated, tater, the query function member of the enclosing multitype object is invoked in order 

10 to retrieve a reference to the interface that has been aggregated. 

Brief Description of the Drawings 

Figure 1 is a block diagram illustrating typical data structures used to represent an object. 
15 Figure 2 is a block diagram illustrating a sample data structure of a spreadsheet object using nested class- 

es. 

Figure 3 is a block diagram showing an aggregate object 

Figure 4 is a block diagram of the data structure layout of an instance of an object of dass S1 . 
Figure 5 is a block diagram of the data structure layout of an object of class S3. 
20 Figures 6Aand 6B are block diagrams illustrating the cooperation between an enclosing object and an 

enclosed object 

Figures 7A. 7B. and 7C are block diagrams of the sequence of adding two objects to a multitype object 
Figure 8 is a block diagram of the data structure layout of an instance of an object of dass S1 . 
Figure 9 Is a flow diagram of the method Addlnterface of the I Multitype interface implemented by a mul- 
25 titype object. 

Figure 10 is a flow diagram of the method Querylnterface of the controlling lUnknown interface for a mul- 
titype object. 

Figure 11 is a block diagram showing the data structure layout of a multitype object corresponding to Fig- 
ure 7C, after the IBasic, IPrint and IDatabase interfaces have been dynamically aggregated using the method 
30 AddObject 

Figure 12 is a pictorial representation of a spreadsheet object and a database query object, which can be 
aggregated together to create an attached database query object 

Figure 13 is a block diagram of an aggregated attached database query object 

35 Detailed Description of the Invention 

The present invention provides a method in a computer system for aggregating objects. Objects can either 
be aggregated statically or dynamically. Using static aggregation, an enclosing object typically has compile 
time knowledge of the exposed interfaces of enclosed objects. The object management interface of the en- 
40 closing object Is therefore customized to return interface pointers to exposed interfaces of endosed objects 
using this knowledge, instances of these statically aggregated objects are created dynamically (at run time). 

Using dynamic aggregation, an enclosing object is Instantiated and can be used to aggregate objects or 
interfaces at run time. The endosing object has no a priori knowledge of the endosed objects or interfaces, 
thus no compile time knowledge is used by the enclosing object Similarly, the enclosed objects and interfaces 
45 have no knowledge of the implementation or the presence of Interfaces of the endosing object, with the ex- 
ception of the controlling object management interface used to aggregate objects and interfaces. Also, a rules 
mechanism is provided to control access to aggregated objects and interfaces. 

Each of these types of aggregation is discussed in turn in the following sections. In a preferred embodi- 
ment, the methods and systems of the present invention are Implemented on a computer system comprising 
50 a central processing unit, memory, and input/output devices. 

Static Aggregation 

In a preferred embodiment of static aggregation, an aggregate object provides a plurality of interfaces to 
65 its clients. The computer program that Instantiates an object is referred to as a client An aggregate object com- 
prises one or more enclosed objects and an implementation of the lUnknown interface, which is referred to as 
the controlling lUnknown interface of the aggregate object An aggregate object exposes to its clients its own 
interfaces and interfaces from the endosed objects. The method Querylnterface of the controlling lUnknown 
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interface returns a pointer to each interface exposed by the aggregate object. The aggre^^^ 
each enclosed object. This instantiation can be performed during construction of the aggregate object or can 
be postponed until an interface of the enclosed object is requested. Each enclosed object contains a pointer 
to the controlling lUnknown interface. The method Query Interface of an exposed interface of an enclosed ob- 
ject IS preferably implemented to invoke the method Querylnterface of an lUnknown interface. When the en- 
closed object is implemented, the developer typically has no knowledge of what interfaces the enclosing object 
may expose. Consequently, the method Querylnterface of an enclosed object invokes the method Queryln- 
terface of the controlling lUnknown interface to retrieve a pointer to the requested Interface. The method Quer- 
ylnterface of the controlling lUnknown Interface is typically implemented with knowledge of all the exposed 
interfaces. When an object Is not enclosed, the controlling lUnknown interface Is the lUnknown interface of 
the object. Conversely, when an object is enclosed, the controlling lUnknown interface is the lUnknown Inter- 
race of the enclosing object. 

In a preferred embodiment, an aggregate object maintains a reference count. When the aggregate object 
IS instantiated, its reference count is set to one. The method Querylnterface of the controlling lUnknown in- 
crements the reference count when a reference is returned to the client. The method AddRef of an exposed 
interface of an enclosed object invokes the method AddRef of the controlling lUnknown interface to increment 
the reference count of the aggregate object. Similarly, the method Release of an exposed interface of an en- 
dosed object invokes the method Release of the controlling lUnknown Interface to decrement the reference 
count of the aggregate object and delete the aggregate object when the reference count equals zero When 
an enclosed object is instantiated, the reference count of the enclosed object is set to one. When the aggregate 
object IS deleted, the method Release of the lUnknown interface of each enclosed object is Invoked to delete 
the enclosed object. 

Figure 3 Is a block diagram showing an aggregate object The aggregate object S3 exposes interfaces A 
B, C. F. and the controlling lUnknown. The aggregate (enclosing) object S3 comprises enclosed object SI Z03 
enclosed object S2 302, and implementation 13 304. The enclosed object S1 implements external Interfaces 
C and D, and the enclosed object S2 implements external interfaces E and F. (An external interface is an in- 
terface of an object that can be exposed by an enclosing object. An Internal interface is an interface of an object 
that cannot be exposed by an enclosing object.) The implementation 13 implements external interfaces A B 
and the controlling lUnknown. A client of the aggregate object S3 need not be aware that the object is an ag' 
gregate. The aggregate object S3 insfantiates objects S1 and S2 either during construction of aggregate object 
S3 or at a later time. The implementation 13 contains pointers to the lUnknown interfaces of objects SI and 
S2. Objects S1 and S2 are initialized to contain a pointer to the controlling lUnknown interface. 

The method Querylnterface of an exposed interface can return a pointer to each exposed Interface and 
increments the reference count of the aggregate object when a pointer is returned. The method Queryl nterface 
of the controlling lUnknown has direct access to the pointers to the lnterfaces~A, B. and controlling lUnknown 
-that implementation 13 implements and invokes the method Querylnterface of the lUnknown interface of the 
enclosed objects to retrieve pointers to the exposed Interfaces - C and F -of enclosed objects S1 and S2 
When a pointer to an exposed Interface Is returned, the method Querylnterface of the controlling lUnknown 
interface increments the reference count of the aggregate object S3 by invoking the method AddRef of the con- 
rollmg lUnknown interface. The method Querylnterface of each exposed interface (other than the controlling 
lUnknown Interface) preferably invokes the method Querylnterface of the controlling lUnknown Interface 
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Codg Tablg 3 

5 void CreatelnstanceSl (lUnknown ♦punkOuter, REFIID iid, void **ppv) 
{ lUnknown 'punk; 

S I ::CreateInstance (punkOuter, &punk); 
punk->QueryInterface (iid, ppv); 
punk->ReIease Q; 

10 } 

class IC: public lUnknov^ 
{//methods ofIC} 

15 class ID: public lUnknown 
{//methods of ID) 

class S I : public lUnknown 
{ 

20 public: 
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static void Create [nstance(lUnknown *punkOuter, lUnknown **ppimk) 
{ S I *pS I = new S 1 (punkOuter); 

pS 1 •>Querylnterface(IID_rUnknown, ppunk); 

) 



void SUIUnknown ♦punkOuter) : m_C(this), m_D(this) 
{ if (punkOuter = NULL) 

m_punkOuter = this; 

else 

m_punkOuter = punkOuter; 
m_refcount = 0; 

} 

class C: public IC 
( 

public: 

voiclC(Sl 'pSl) {m_pSl =pSl;> 

virtual boolean Querylnterfacc (REFIID iid, void **ppv) 
{ return mj3Sl->m_punkOuter->QueryInterfacc(iid, ppv);} 

virtual void AddRef() 

{ ni_pSl->m_punkOuter->AddRef();} 

virtual void Release() 

{ ni_pSl->m_punkOuter->Release();} 

// other methods of IC 

private: 

SI *m_pSl; 

} 

friend C; 

C m_C; 

class D: public [D 
{ 

public: 

voidD(Sl »pSl) {m_pSl =pSl;} 

virtual boolean Querylnterfacc (REFIID iid, void **ppv) 
{ return m_pSl->m_punkOuter->Querylnterface(iid, ppv);} 

virtual void AddRef() 

{ m jaS 1 ->m_punkOuter-> AddRefO ; } 

virtual void ReleaseQ 

{ Tn_pSl->m_punkOuter->ReleaseO;} 

// other methods of ID 

private: 

SI *m_pSl; 

} 
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friend D; 

D m_D; 



boolean Query Interface (REFIID iid, void **ppv) 
ret = TRUE; 
switch (iid) 
{ case IID_C: 

*ppv = &m_C; 

m_punkOuter->AddReflQ; 

break; 
case IID_D: 

'•ppv = &m_D; 

m_punkOuter-> AddRefO ; 

break; 
case IID_IUnknown: 

*ppv = This; 

AddRefO; 

break; 

default: 

ret = FALSE; 

} 

return ret; 



virtual void AddRef(){ m_refcount++;} 

virtual void ReleaseO {if (-m refcount = 0) delete this;} 



*m_purikOuter; 
m_refcounl; 

35 

Code Table 3 contains C++ pseudocode for a preferred d ass definition of the object S1, which can be en- 
closed in an aggregate (an aggregatable object) along with a global function that creates an instance of the 
object. The classes {Unknown, IC, and ID are interfaces that define the methods of each interface. The dass 
SI implements the I Unknown interface, the IC interface, and the ID interface. The class S1 implements the 

40 IC and ID interfaces as external interfaces. Figure 4 is a block diagram of the data structure layout of an In- 
stance of an object of dass S1. Instance structure 401 contains the data members of dass S1 (m_C, m_D, 
m_punkOuter, m_refcount) and a pointer to the virtual function table pointer (S1::vfptr). The data members 
m_C and m_D are instances of an object of classes C and D, respectively. Classes C and D are friends of 
class SI, which allows C and D objects to access the private members of class S1. The virtual function table 

45 pointer S1::vfptr points to virtual function table 402, the virtual function table piointer within data member m_C 
S1::C::vfptr points to virtual function table 403. and the virtual function table pointer within data member m_D 
S1::D::vfptr points to virtual function table 403A. Virtual function table 402 contains pointers to the virtual func- 
tions defined for the lUnknown interface, virtual function table 403 contains pointer to the virtual functions de- 
fined for the C Interface, and virtual function table 403A contains pointers to the virtual functions defined for 

so D Interface. The ellipsis in virtual function tables 403 and 403A indicates pointers to additional function mem- 
bers of classes C and D, respectively. Functions 404 through 408 are the function members of class S1 . Func- 
tion 407 Is the constructor for class 81. Function 408 Is the function Createlnstance for dass SI. Functions 
409 through 412 are the function members of class C. Function 412 Is the constructor for dass C. Functions 
413 through 416 are the function members of dass D. Function 416 is the constructor for class D. 

55 As shown In Code Table 3, the method 31 ::Querylnterface returns a pointerto the interface C, the interface 

D, or the interface lUnknown. When a pointer to the interface Cor Interface D is returned, the method S1:Quer- 
ylnterface invokes the method S1::AddRef to increment the reference count for the 31 object. The method 
31 ::AddRef increments the reference count, and the method SI ::Release decrements the reference count and 



5 public: 

virtual 
{ 
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lUnknown 
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deletes the S1 object when the reference count is zero. When a pointer to the internee C or interface D is 
returned, the method S1:Querylnterface Invokes the method AddRef of the controlling tUnknown interface, 
which when the S1 object is not aggregated is the method S1::AddRef. 

The global function Create! nstanceSI creates an instance of an object of class SI. A client invokes this 

5 function to instantiate an object of class S1 . Thus, a client can instantiate an object of class SI without having 
access to the S1 dass definition atcompile time or run time. The function Create I nstanceSI is passed a pointer 
to the controlling lUnknown (punkOuter) when the instantiated S1 object is enclosed within an aggregate object 
and an identifier (iid) of an interface to return. The function Createl nstanceSI returns a pointer (ppv) to the 
identified interface. The function CreatelnstanceSI invokes the method S1::CreateInstance passing the para- 

10 meter punkOuter. The method S1::Createtnstance Instantiates an 81 object and returns a pointer (punk) to 
the lUnknown Interface of the S1 object. The function CreatelnstanceSI invokes the method Querylnterface 
of the S1 object to retrieve a pointer to the Identified interface. The function CreatelnstanceSI then invokes 
the method Release of the S1 object because the temporary pointer punk is no longer needed. 

The method S1::CreateInstance instantiates an S1 object and returns a pointer (ppunk) to the lUnknown 

15 interface of the S1 object. The method S1:;Createlnstance is passed a pointer (punkOuter) to the controlling 
lUnknown. The method S1 ::Createlnstance uses operator new to instantiate the S1 object. During instantiation, 
the constructor S1::S1 is invoked and passed the value of the parameter punkOuter. After the SI object is con- 
structed, the method S1::Createlnstance invokes the method S1::Querylnterface to retrieve a pointer to the 
lUnknown interface of the S1 object. 

20 The constructor S1 ::S1 initializes the data members m_C, m_D, m_punkOuter, and m_ref count The con- 

structor S1::S1 is passed the parameter punkOuter. During instantiation of the data members m_C and m_D, 
the constructors C::C and D::D are invoked and passed the this pointer for the S1 object. If the value of the 
parameter punkOuter is NULL, the constructor S1::S1 sets the data member m_punkOuterto the value of the 
this pointer (which points to the newly instantiated S1 object). If the value of the parameter punkOuter is non- 
25 NULL, the constructor S1 ::S1 sets the data member m_punkOuter to the value of parameter punkOuter. Data 
member m_punkOuter points to the value of the controlling lUnknown of the aggregate when the SI object is 
enclosed and points to the controlling lUnknown of the S1 object when the S1 object is not enclosed. The con- 
structor S1::S1 also initializes the data member m_refcount to zero. 

The constructor C::C is passed a pointer to the S1 object. The constructor C::C stores the passed pointer 

30 in data member C::m_pS1. The data member C::m_pS1 is used by the methods of class C to access the data 
member S1 ::m_punkOuter. 

The methods C::Query Interface, C::AddRef, and C::Release invoke the corresponding methods of the lUn- 
known interface pointed to by data member 81 ::m_punkOuter. which when the 81 object is enclosed, points 
to the controlling lUnknown interface of the aggregate. 

35 The constructor and other methods of class D are analogous to those of class C. 

Figure 4 shows an instance of an S1 object that is not part of an aggregate. The data members 
S1::C::m_pS1, S1::D::mjpS1, andS1::m_punkOuterare Initialized to pointer to the S1 object itself. The meth- 
ods Querylnterface, AddRef, and Release of the data members m_C and m_D Invoke the lUnknown methods 
of the interface of the S1 object. 

40 The S2 object that implements interfaces E and F is analogous to the S1 object as described above. 
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Code Table 4 

void CreatelnstflnceS3 (lUnknown *punkOurer, REFIID iid, void **ppv) 
{ lUnknown *piink; 

S3;:Createlnstance (punkOuter, &punk); 

punk->Query interface (iid, ppv); 

pxink->Release (); 

} 

class lA: public lUnknown 
{ // methods of class lA} 

class IB: public RJnknown 
{ // methods of class IB} 

class S3: public lUnknown 
{ 

pubiic: 

static void Create I nstance( lUnknown 'punkOuter, lUnknown •*ppunk) 
{ S3 *pS3 = new S3(punkOuter); 

CreatelnstanceS !(pS3->m_punkOuter, IID IUnknown, pS3->m_piinkS I ); 

CreateInstanceS2CpS3->m_punkOuter, lIDJUnknown, pS3->m_punkS2); 

pS3->Queiy Interface(IID_IUnknown, ppunk); } 

private: 

void S3 (lUnknown * punkOuter) : m_A(this), m_B(this) 
{ if (punkOuter === N U LL) 

m_punkOuter = this; 

else 

m_punkOuter = punkOuter; 
m_refcount = 0;} 

void-SjC) {m_punkSl->ReleaseO; 

m_punkS2->ReleaseO; ) 

class A: public lA 

{ 

public: 

void A(S3 *pS3) {m_pS3 = pS3} 

virtual boolean Query Interface (REFIID iid, void **ppv) 
{ return m_pS3->m_j)unkOuter->QueryInterface(iid, ppv);} 

virtual void AddRef() 

{ m_pS3 ->m_pun kOuter-> AddRefQ ; } 

virtual void Release() 

{ rajpS3->ni_punkOuter->ReleaseO;} 
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W other methods of I A 

private: 

S3 *m_pS3; 

}; 

friend A; 

A ni_A; 

class B: public IB 
{ 

public: 

void B(S3 *pS3) {m_pS3 = pS3} 

virtual boolean Querylntcrfacc (REFIID iid, void **ppv) 
{ return m_pS3->m_punkOuter->QueryInterface(iid, ppv);} 

virtual void AddRef() 

{ m_pS3->m_j)unkOuter->AddRefO;} 

virtual void ReleaseQ 

{ m_pS3->m_punkOuter->Release();} 

W other methods of IB 

private: 

S3 ♦m_pS3; 

}; 

friend B; 

B m_B; 



virtual boolean Query!nterface{REFlID iid, void **ppv) 
{ ret = TRUE; 

switch (iid) 
{ case IID_C: 

ret = m_punkSl->QueryInterface(iid, ppv); 

break; 
case IID F: 

ret = m j3unkS2->QueryInterface(iid, ppv); 

break; 
case IID_A: 

*ppv = &m_A; 

m_punkOuter->AddRefl[); 

break; 
case IID_B: 

*ppv = &m_B; 

m_punkOuter->AddRefl[); 

break; 
case IID lUnknown: 

♦ppv = this; 

AddRefO; 

break; 

default: 

ret = FALSE; 

} 
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return ret; 

) 

virtual void AddRefO { m_refcount++;} 
virtual void Release() {if (--m_refcount = 0) delete this;} 

♦m_punkOuter; 
m_refcount; 
*m_puiikSl: 
*m_punkS2; 

15 

Code Table 4 contains C-f-+ pseudocode for a preferred class definition of an aggregate object. The class 
S3 exposes the interfaces I Unknown. A, B, C, and F. To provide the C interface, the dass S3 encloses an S1 
object and exposes the C interface. To provide the F interface, the class S3 encloses an S2 object and exposes 
the F interface. The S3 object exposes the C and F interfaces by returning pointers to the C and F interfaces 

20 through the method Query Interface of the controlling lUnknown interface. The D interface of the 31 object 
and the E interface of the S2 object are external interfaces, but the S3 object does not expose these interfaces. 

The methods S3::Querylnterface, S3::AddRef, and S3:: Release compose the controlling lUnknown inter- 
face for the aggregate. The method S3:: Query Interface returns a pointer to the controlling lUnknown, A, B, 
or F interfaces. When a pointer to the controlling lUnknown interface is returned, the method S3::Querylnter- 

25 face invokes the method S3::AddRef to increment the reference count for the S3 object. The method S3::Ad- 
dRef increments the reference count, and the method S3::Release decrements the reference count and deletes 
the S3 object when the reference count is zero. When a pointer to the A, B, C, or F Interfaces is returned, the 
method S3::Querylnterface invokes the method Add Ref of the controlling lUnknown interface, which when the 
S3 object is not aggregated is the method S3:: Add Ref. 

30 The global function CreatelnstanceS3 creates an instance of an object of class S3. A client invokes this 

function to instantiate an object of class S3. Thus, a client can instantiate an object of class S3 without having 
access to the S3 dass definition at compi le time or run time. The function Createln&tanceS3 is passed a pointer 
to the controlling lUnknown interface (punkOuter) when the instantiated S3 object is endosed within an ag- 
gregate object and an identifier (iid) of an Interface exposed by the dass S3 to return. The function Createln- 

35 stanceS3 returns a pointer (ppv) to the identified interface. The function CreatelnstanceS3 invokes the method 
S3::Createlnstance passing the parameter punkOuter. The method S3:: Create Instance instantiates an S3 ob- 
ject and returns a pointer (ppunk) to the lUnknown interface of the S3 object. The function CreatelnstanceS3 
then invokes the method S3::Querylnterface to retrieve a pointer to the identified interface. The function Cre- 
atelnstanceS3 then invokes the method S3:: Release because the temporary pointer punk is no longer needed. 

40 The method S3::Createlnstance instantiates an S3 object and returns a pointer (ppunk) to the lUnknown 

interface of the S3 object. The method S3::Createlnstance Is passed a pointer (punkOuter) to the controlling 
lUnknown. The method S3::Createlnstance uses operator new to Instantiate the S3 object. During instantiation, 
the constructor S3::S3 is invoked and passed the value of the parameter punkOuter. After the S3 object is con- 
structed, the method S3::Createlnstance invokes the function CreatelnstanceSI to create the enclosed S1 ob- 

45 jecL The method S3::Createlnstance passes the parameter pS3->m_punkOuter and the interface Identifier for 
the lUnknown interface and is returned a pointer to the lUnknown interface of the SI object. The method 
S3::Create1nstance stores the returned pointer in data member S3::m_punkS1. The method S3::Createln- 
stance then Invokes the function Create! nstanceS2 to create an S2 object in a manner analogous to the cre- 
ation of the SI object. The method S3::Createlnstance invokes the method S3::Querylnterface to retrieve a 

50 pointerto the lUnknown interface. 

The method S3::AddRef Increments the reference count of the S3 object. The method S3:: Release dec- 
rements the reference count When the reference counts Is zero, the method S3::Release deletes the S3 ob- 
ject 

The constructor S3::S3 initializes the data members m_A, m_B, m_punkOuter, and m_refcount The con- 
55 structor S3::S3 is passed the parameter punkOuter. During instantiation of the data members m_Aand m_B, 
the constructors A:: A and B::B are invoked and passed the this pointer for the S3 object. If the value of the 
parameter punkOuter is NULL, the constructor S3::S3 sets the data member m__punkOuter to the value of the 
this pointer (which points to the newly instantiated S3 object). If the value of the parameter punkOuter is non- 
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NULL, the constructor S3::S3 sets the data member m_punkOuter to the value of parameter punkOuter. Data 
member m_punkOuter points to the value of the controlling lUn known Interface of the aggregate when the S3 
object is enclosed and points to the lUnknown interface of the S3 object when the S3 object is not enclosed. 
The constructor S3::S3 initializes the data member m_refcount to zero. 
5 The destructor S3:: -33 invokes the method S1:: Release to decrennentthe reference count of the enclosed 

S1 object. Since the reference count was set to one during instantiatkin of the S1 object, the method S1::Re- 
lease deletes the 31 object The destructor S3:: -33 decrements the reference count of the S2 object in an 
analogous manner. 

The methods of the A and B interfaces have an analogous behavior to the methods of the C interface. 

10 Thus, the A and B interface can be exposed when an S3 object is enclosed. 

Figure 5 is a block diagram showing the data structure layout of an S3 object The data structure layout 
comprises instance data 501 , virtual function tables 502, 503, and 504, methods 505 through 51 7, and instanc- 
es of an S1 object 401 -41 6 and an S2 object 519. The Instance data 501 contains a pointer to the virtual function 
table for the controlling lUnknown Interface, data members m_Aand m_B which are instances of class A and 

15 B, data member m_punkOuter which points to the lUnknown interface of the S3 object, data member m_re- 
fcount which contains the reference count for the S3 object, data member m_punkS1 which points to the lUn- 
known interface of the enclosed S1 object, and data memberm_punkS2 which points to the lUnknown interface 
of the enclosed S2 object 519. When the enclosed SI object is instantiated, its data member 81 ::m_j>unkOuter 
is initialized to point to the lUnknown interface of the S3 object Similarly, when the enclosed S2 object Is in- 

20 stantiated, its data member S2::m_punkOuter is initialized to point to the lUnknown interface of the S3 object. 

Figures 6A and 6B are block diagrams illustrating the cooperation between an enclosing object and an 
enclosed object Figure 6A is a block diagram illustrating an object of class SI that is not enclosed within an- 
other object The class S1 object 601 includes data member m_punkOuter, which points to the lUnknown in- 
terface and methods 603, 604, 605, and 606. The method IUnknown::Qu6rylnterface 603 returns a pointer to 

25 the requested interface and increments the reference count. The methods C::Query Interface 605 and C::Ad- 
dRef 606 Invoke the corresponding methods of the lUnknown interface. The implementation of the methods 
of class D (not shown) are analogous to those of class C. Figure 6B is a block diagram illustrating an object 
of class S3 that encloses objects of class 81 and 82. The S2 object, which is analogous to the SI object, is 
not shown. The data member m_punkOuter 602 of the class 81 object 601 points to the lUnknown interface 

30 of the dass S3 object 61 0. The method lUnknown: :Querylnterface 613 returns a pointer to each of the exposed 
objects and invokes the method lUnknown: :Querylnterface 603 pointed to by data member m_punkS1 619 to 
retrieve a pointer to the C interface. The data member m_punkOuter 612 points to the lUnknown interface of 
the class S3 object 610. The methods Querylnterface 615 and 617 of the class A and B objects invoke the 
methods pointed to by data memt>er m_punkOuter 612. 

35 In the above-described embodiment of the present invention, the method Querylnterface of the controlling 

lUnknown interface of an aggregate invokes the method Querylnterface of the lUnknown Interface of enclosed 
objects to retrieve pointers to the exposed Interfaces. In an alternate embodiment of the present invention, an 
enclosing object can cache pointers to interfaces of enclosed objects that the enclosing object exposes. Thus, 
when the method Querylnterface of the controlling lUnknown is invoked, the method can retrieve and return 

40 the cached pointers after calling the method AddRef of the controlling lUnknown interface, rather than invoke 
the method Querylnterface of the lUnknown Interface of the enclosed object. To Implement this alternate em- 
bodiment, an enclosing object defines a data member for each cached pointer. When the enclosed object Is 
instantiated (typically during construction of the enclosing object), the method Querylnterface of the lUnknown 
interface of the enclosed object is invoked to retrieve a pointer of the exposed Interface. It is preferred that 

45 the retrieved pointer Is not reference counted so that the enclosing object effectively maintains only one pointer 
(e.g., S3::m_punkS1) to an enclosed object The enclosed object can then be deleted by a single call to the 
method Release. Therefore, after the pointer is cached, the method Release of the exposed interface is in- 
voked to remove the reference count attributable to the cached pointer. 

In the above-described embodiment of the present Invention, the Implementation of the method Queryln- 

50 terface of the controlling lUnknown interface includes a switch statement that specifies which Interfaces are 
exposed. For example, the switch statement of the method S3::Querylnterface includes a case label for each 
exposed Interface A, B, C, F, and the controlling lUnknown. Thus, the exposed Interfaces are statically defined 
during implementation of the enclosing object In an alternate embodiment, the method Querylnterface of the 
controlling lUnknown interface can t>e implemented without specific knowledge of the external interfaces of 

55 the enclosed objects. When the method Querylnterface is requested to return a pointer to an interface that it 
does not implement, the method can invoke the method Querylnterface of the lUnknown interfaces of the en- 
closed objects to retrieve a pointer to the identified interface, if implemented by an enclosed object Code Table 
5 contains C++ pseudocode for a preferred implementation of the method Querylnterface of the controlling 
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■Unknown of a S3 object that implements this alternate embodiment. In addition to returning a pointer to each 
external Interface of the enclosed objects, the method Query Interface of the controlling {Unknown could be 
implemented to not expose certain external interfaces, while exposing all other external interfaces. 



Code Table 5 



virtual boolean Querylnterface (REFIID iid, void **ppv) 
^0 { ret = TRUE; 

switch (iid) 
{ case IID A: 

•ppv = &m_A; 

ra_punkOuter->AddRef(); 
15 break; 

case IID_B: 

*ppv = &m_B; 

m_punkOuter->AddRef(); 

break; 

20 case IID_1Unknown: 

*ppv = this; 
AddRefO; 
break; 

default: 

25 if (m_pimkSl->QueryInterfeice (iid, ppv)) { return ret;} ; 

if (m_punkS2->QueryInterfece (iid, ppv)) { return ret;); 
ret = FALSE; 

} 

return ret; 



In the atx}ve-d escribed embodiments, error checking has not been described. It is preferred that various 
types of error checking are performed to ensure that an aggregate is properly created. For example, If an en- 

35 closing object tries to enclose an object that is not aggregatable, then the instantiation of the enclosing object 
should fail (e.g., the function CreatelnstanceSI returns a flag indicating failure). 

In the at>ove-descrit>ed embodiments, an aggregate object can itself be an enclosed object within an en- 
closing object. This enclosing (nesting) can occur to any depth. Alternately, an aggregate object can be imple- 
mented to t>e non-aggregable. The function CreatelnstanceXX for the class XX can return a flag indicating a 

40 failure when the parameter punkOuter is non-null, that is, when aggregation is desired. 

In the above-described embadiment, an object for each external interface of an aggregable abject is In- 
stantiated as a data member of the aggregable object. In an alternate embodiment, the external interfaces are 
inherited by the aggregable object, rather than implemented as data members of the aggregable object. Code 
Table 6 contains C++ pseudocode for a preferred class definition S1 of an aggregable class with externa! in- 

45 terfaces C and D. The class S1 Inherits the abstract classes IC and ID. The implementations of the IC and ID 
interfaces need not store a pointer to the derived dass S1 to access the data member m__punkOuter, but a 
special, non-inherited implementation of the I Unknown interface (lUnknownSI) is needed. Conversely, the im- 
plementations of the IC and ID interfaces, as shown in Code Table 3. store the pointer to the derived class S1 
In the data member m_pS1. One skilled In the art would appreciated that other implementations using inherl- 

50 tance of interfaces are possible. 
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class SI : public IC. public ID 
{ public: 

virtual boolean Query Interface (REFIID iid, void •*ppv) 
{ return m_punkOuter->QueryInterface(iid, ppv);} 

virtual void AddRef() 

{ m_punkOuter->AddRefl;);} 

virtual void ReleaseQ 

{ m_punkOuter->AddRef();} 

// implementation of IC and ID 

private: 

class 1 Unknowns 1 : public lUnknown 

{ 

public: 

lUnknownSl (Si *pSl) 
{ m_pSl = pSl; 
m_refcount = 0;} 

virtual boolean Querylnterface (REFIID iid, void 

{ret = TRUE; 

switch (iid) 

{case lID_IUnknown: 

•ppv - this; 

AddRefO; 

break; 
case 1ID_C; 

*ppv = (IC •}m_pSl; 

m_pS l->m_punkOuter-> AddRefO; 

break; 
case IID_D: 

*ppv = (ID *)m_pSl; 

m_pS 1 ->m_punkOuter->AddRef(); 

break; 

default: 
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ret = FALSE; 

}; 

} 

' virtual void AddRefO {m_refcount++;} 

virtual void Reiease() {if (-m_refcount = 0) delete m_pSl ;} 

private: 

int m_refcount; 
SI m_pSl; 

} 

friend lUnknownS I ; 

lUnknownS I mJUnknownS 1 ; 

public: 

static void Createlnstance (lUnknown ♦punkOuter, lUnknown **ppunk) 
{ S I *pS 1 = new S 1 (punkOuter); 

20 pSl->Querylnterfece(IID_Unknown, ppunk); 

} 

private: 

void SI (lUnknown *punkOuter) : m_IUnknownSl(this) 
25 { if (punkOuter = NULL) 

m_punkOuter = &m_IUiiknovmSl ; 



ni_punkOuter = punkOuter; 



else 
} 

lUnknown ra_punkOuter; 



35 Dynamic Aggregation 

In a preferred enribodiment of dynamic aggregation, interface Instances are combined by adding them to 
an enciosing object at any time after the creation of the enclosing object. In this manner, a new or changed 
interface can be combined with an existing (base) object to alter the apparent behavior of the base object after 

40 the code for the base object has been compiled or linked. That Is, although the behavksrof the base object (as 
implemented by the methods of the base object) appears outwardly to have changed, the methods implement- 
ing the behavior of the base object have not actually changed. The base object Is enclosed within the enclosing 
object and the new or changed interfaces are thereafter added. 

When an external request Is made to access to a particular interface, the enclosing object is responsible 

45 for determining which Interface to return and how to Invoke the requested interface If more than one matching 
Interface exists. For example, if three I Print interfaces exist in the aggregate object, the enclosing object de- 
termines which IPrInt interface to return or whether to return Its own IPrint Interface, which knows how to Invoke 
a combination of the methods of the other I Print Interfaces. The enclosing object can make this detenmlnatlon 
either from a fixed or specifiable set of combining rules. 

60 These combining rules can be used to override the standard behavior of an enclosed base object by pro- 

viding access to a new implementation of a previously defined interface of the enclosed base object. These 
rules can also be used to enhance the behavior of an enclosed base object by adding capabilities not Initially 
defined as part of the enclosed base object. Both override and enhancement capabilities are provided by add- 
ing a new or changed interface to the base object. In addition to these capabilities, a standard enclosing object 

55 can Implement default behaviors for enclosed objects (Interfaces that implement methods to invoke If not pro- 
vided for by the enclosed objects or added interfaces). Or, a standard enclosing object can implement con- 
trolling (overriding) behavior for a method typically present for all enclosed objects (such as printing). 

In a preferred embodiment, an object can be modified dynamically by allowing interface instances (imple- 
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mented by objects) to be aggregated together during the execution of a client program. The computer program 
that instantiates an object is a client program. Aggregation is the process of combining the capabilities of sev- 
eral distinct objects by enclosing their respective interfaces within an enclosing object. The enclosing object 
is then responsible for supporting access to all interfaces it wishes to expose through the enclosing object's 
5 implementation of a controlling I Unknown interface. 

Static aggregation requires that the enclosing object have advance knowledge of the interfaces (objects) 
it wishes to aggregate. Using static aggregation, a programmer decides, in advance, which of its aggregate 
object Interfaces the enclosing object should expose and then implements the Querylnterface method of the 
controlling lUnknown of the enclosing object to return pointers to these exposed interfaces when requested. 
10 The Querylnterface method of the controlling lUnknown accomplishes this task by maintaining references to 
the corresponding lUnknown Interfaces of the Individual enclosed objects. (These references are created when 
the enclosing object instantiates enclosed objects.) When a request is received for a reference to an exposed 
interface of one of the enclosed objects, the Querylnterface method of the controlling lUnknown invokes the 
corresponding lUnknown interface of the enclosed object to respond to the request. Because enclosed objects 
15 have no knowledge of what interfaces the enclosing object exposes, all external requests received by an en- 
closed object are passed on to the enclosing object thereby enabling access to the interfaces defined in the 
other enclosed objects aggregated together. 

The present invention also supports the dynamic aggregation of interfaces. In a preferred emtxKJiment, 
an enclosing object provides a method for registering instantiated interfaces and for later retrieving references 
20 to them. In addition, when an interface is requested from the aggregate object, the present inventron provides 
a method for modifying the determination of which interface(s) to retrieve and how to invoke them in combin- 
ation if more than one instance of the same interface is present in the aggregate object. 

In a preferred embodiment, dynamic aggregation is implemented using a multitype object. A muititype ob- 
ject is an object capable of aggregating objects of varying types, hence its name. Only interfaces that have 
25 been coded such that they are capable of being aggregated can be enclosed within a multitype object. (That 
is, for example, such interfaces can forward interface and reference counting requests to an enclosing object.) 
A multitype object provides an IMultitype interface for requesting the aggregation of particular interfaces or 
objects and for adding rules to determine how to invoke a requested interface. Code Table 7 contains pseu- 
docode for a preferred definition of the IMultitype interface. 

30 

Codg r?^blff 7 

class IMultiType: public lUnknown { 

virtual HRESULT AddObject (ULONG list, BOOLEAN headoflist, 
lUnknown *punkobj) = 0; 

virtual HRESULT Addlnterfacc (REFIID iid, ULONG list, BOOLEAN headoflist, 

void •*ppv = 0; 
virtual HRESULT AddRule (REFIID iid, IRULE ♦pmie) = 0; 
virtual Enum (ULONG i; REFIID iid. ULONG list, BOOLEAN headoflist; 
void **ppv) = 0; 

} 

45 Figures 7A, 7B, and 7C are block diagrams of the sequence of adding two objects to a multitype object. 

Figure 7Ais a block diagram of an instance of a multitype object. The object MTO 7A01 implements an exposed 
interface, the IMultitype interface MT, and a controlling lUnknown. When an external interface is added to the 
multitype object, the multitype object becomes an aggregate object The multitype object implementation con- 
tains three lists 7A02, 7A09, and 7A10 of Interfaces it has added to the aggregation. The multitype object uses 

50 these lists to invoke the various interfaces of its enclosed aggregate objects through the multitype object's 
controlling lUnknown Interface. The multitype object also contains a list of rules 7A11 for accessing and com- 
bining Interfaces from the Interface lists 7A02, 7A09, and 7A10. 

The interaction of these different lists gives the multitype object powerful capabilities. The list of rules 
7A11, which can be fbced or specified using the AddRule method, specifies the interaction and use of the dif- 

55 ferent interface lists for a particular interface. Hence, there can be rules for selecting other rules as well as 
rules for selecting and combining particular interfaces. Three different interface lists 7A02, 7A09. and 7A10 
are provided in orderto support override, enhancement, default, and controlling capabilities. When an Interface 
Is added to the multitype object, the client program creating the aggregate specifies the list to be used in adding 
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the interface. List 7A02 comprises the normal list, list 7A09 comprises the default list, and list 7A10 comprises 
the override list. Basically, the override list is intended Implement override and controlling capabilities by point- 
ing to interfaces that need to be accessed before the interfaces on the normal list. The default list is intended 
to point to interfaces that are accessed only when the ovenride and normal lists do not contain a requested 

5 interface. The interaction of these lists is discussed in greater detail In the description of the I Rules interface. 

Figure 7B is a block diagram Illustrating the multltype object MTO after aggregating the IBasic interface 
using the AddObject method. The AddObject method adds all of the interfaces of a specified object to a mul- 
titype object. The aggregate object MTO 7B01 comprises the multitype interface discussed with reference to 
Figure 7A and an enclosed spreadsheet object S1 7B04. The enclosed object S1 implements an Instance of 

10 the external interface IBasic (B), an Instance of the external interface IPrint (P). and an Instance of lUnknown. 
(An external interface is an Interface of an object that is exposed by an enclosing object. An internal interface 
Is an interface of an object that is not exposed by an enclosing object.) When the enclosed object S1 is added 
to the normal list of the multitype object MTO, the normal list of aggregated Interfaces 7B02 contains a single 
element 7B03, which identifies the lUnknown interface of the enclosed object S1. The S1 lUnknown interface 

15 returns pointers to the external interfaces B and P upon request. Because S1 is aggregatable. when S1 is in- 
stantiated, it is passed a pointer 7B05 to the enclosing object MTO, which can be used subsequently to access 
the other interfaces aggregated as part of object MTO. 

Figure 7C is a block diagram illustrating the multitype object MTO of the result after adding the IDatabase 
interface using the method AddObject. At this point, the aggregate object MTO 7C01 comprises the IMultitype 

20 interface, discussed with reference to Figure 7A; an enclosed spreadsheet object S1 , discussed with reference 
to Figure 7B; and an enclosed database object S2 7C07. which Implements database capabilities. The en- 
closed object S2 implements an instance of the external Interface IDatabase (D) and an instance of lUnknown. 
When the enclosed object 82 is added to the multitype object MTO using the method AddObject of the IMul- 
titype interface, the normal list of aggregated interfaces 7C02 contains two elements 7C03 and 7C06. Element 

25 7C06 Identifies the lUnknown interface of the enclosed object S2. Similar to S1, the S2 lUnknown interface 
is able to return a pointer to the external interface D and contains a pointer 7C08 to the enclosing object MTO 
for access to the other MTO interfaces. 

One skilled in the art would recognize that many alternative embodiments of the data structures used to 
keep track of the added interfaces and objects are possible. For example, one could vary the number and kind 

30 of lists used. In particular, one could have only one list or make the override or default lists optional. Also, one 
could require that each list element only point to the precise interface to be aggregated and not the lUnknown 
of the object when an entire object is aggregated (only support an Addlnterfaca style multitype object). Or, al- 
ternatively, one could require that each list element point to the lUnknown of the object regardless of what in- 
terface is added to the aggregation (only support an AddObject style multitype object). In addition, one could 

35 use other list Implementations Including various sorted lists or hash tables of Interface Identifiers. 

Code Table 8 

^ void CreatelnstanceSl (lUnknown *punkOuter, REFIID iid. void **ppv) 
{ lUnknown *punk; 

SI "Create Instance (pimkOuter, &punk); 
punk->QueryInterface (iid, ppv); 
punk->Rclease (); 

45 ) 

class IBasic: public lUnknown 
{ virtual void File () = 0; 

virtual void Edit () = 0; 
^ virtual void Fonnula () = 0; 

virtual void Format () = 0; 
virtual void GetCell () = 0; 

> 

class IPrint: public lUnknown 

{ virtual void Print (void **ppobj) = 0; 

} 
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class SI : public lUnknown 
{ 

public: 

static void CreateInstance(IUnknown *punkOuter, lUnknown **ppunk) 
{ S 1 ♦ pS 1 = new S 1 (ptmkOuter); 

pSl->QueryInterface(I!D_IUnknown, ppimk); 

} 

private: 

void SI (lUnknown *punkOuter) : m_B(this), m_P(this) 
{ if (punkOuter = NULL) 

mjJunkOuter = this; 

else 

m junkOuter = punkOuter; 
m refcount = 0; 

} 

class B: public TBasic 
{ 

public: 

voidB(Sl *pSl) {mj)Sl =pSl;} 

virtual boolean Querylnterface (REFIID iid, void **ppv) 
{ return m_pSl->m_punkOuter->QueryInterfece(iid, ppv);} 

virtual void AddRefQ 

{ m jpS I ->m_pimkOutcr->AddRcfO; } 

virtual void ReleaseQ 

{ m_pS I ->m_punkOuter->ReleaseO; } 

// other methods of IBasic including File, Edit, Formula, Format, GetCell 

private: 

SI •m_pSl; 

} 

friend B; 

B m_B; 

class P: public IPrint 

{ 

public: 

void P(S1 *pSI> {mjpSl ^ pSl;} 

virtual boolean Querylnterface (REFIID iid, void '^ppv) 
{ return m_pSl->m_punkOuter->Querylnterface(iid. ppv);} 

virtual void AddRefQ 

{ m_pSl->m_punkOuter->AddRef();} 

virtual void ReleaseO 

{ m_pSl->m_punkOuter->ReleaseO;) 

// other methods of IPrint including Print 
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15 



private: 

SI *m_pSl; 

} 

friend P; 
P m_P; 

public: 

virtual boolean Query Interface (REFITD iid, void **ppv) 
{ ret ^ TRUE; 

switch (iid) { 
case IID B: 

♦ppv = &m_B; 
m_punkOuter->AddRef(); 
break; 
case IID^P: 

♦ppv = &in_P; 

m_punkOuter->AddRcfO; 
break; 

20 case IID_rUnknown: 

*ppv = this; 
AddRefO; 
break; 

default: 

25 ret = FALSE; 

} 

return ret; 

} 

virtual void AddRef(){ m_refcount-H-;} 

virtual void ReleascQ {if (— m refcount = 0) delete this;} 

private: 

lUnknowTi *in_punkOuter; 
int m_refcount; 

} 



40 Code Table 8 contains C+-t- pseudocode for a preferred class definition of the object S1 in Figures 7A-7Cp 

which can be enclosed in an aggregate (an aggregatable object) along with a global function that creates an 
instance of the S1 object. The classes lUnknown, IBasic, and IPrlnt are interfaces that define the methods of 
each Interface comprising S1. The dass S1 implements the {Unknown interface, the IBasic interface, and the 
IPrint interface. The IBasic and IPrint interfaces are implemented as external interfaces. 

45 Figure 8 is a block diagram of the data structure layout of an instance of an object of class S1. Instance 

structure 801 contains the data members of class S1 (m_B, m_P, m_punkOuter) and the virtual function table 
pointer (S1::vfptr). The data members m_B and m_P are instances of objects of classes B and P, respectively 
(which are class implementations of the interfaces IBasic and IPrint). Data members m_B and m_P are friends 
of class S1, which allows m_B and m_P objects to access the private members of ciass S1, such as m_pun- 

50 kOuter. The virtual function table pointerS1::vfptr points to virtual function table 802, the virtual function table 
pointer within data mennber m_B, S1 ::B::vfptr, points to virtual f unctbn table 803, and the virtual function table 
pointer within data member m_R S1::P::vfptr, points to virtual function table 804. Vlrtuai function table 802 
contains pointers to the virtual functions (methods) defined for the oontroliing lUnknown interface, virtual func- 
tion table 803 contains pointers to the virtual functions defined for the IBasic interface, and virtual function 

55 table 804 contains pointers to the virtual functions defined for the IPrint interface. Methods 805 through 809 
are the function membiers of class S1. Method 808 is the constructor for dass S1. Method 809 is the Crea- 
telnstance method for class S1. Methods 810 through 818 are the function members of class B. Method 813 
is the constructor for class B. Methods 819 through 823 are the function members of dass P. Method 823 is 
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the constmctorfor class P. Because Figure 8 shows an instance of an S1 object that is not part of an aggregate, 
the data members S1::B::m_pS1, S1::P::m_pS1, and S1::m_punkOuter (pointers to the enclosing object) are 
initialized to point to the S1 object itself. 

The object S1 as defined by Code Table 8 conforms to the requirements for an aggregatable object dis- 

5 cussed with reference to static aggregation. For the purposes of dynamic aggregation, Code Table 8 illustrates 
how S1 can automatically communicate with its enclosing object when it is aggregated and what is returned 
from the function S1 ::Query Interface. Specifically, upon creation of an S1 object, a pointer to the controlling 
{Unknown interface of an enclosing multitype object is passed to the method Createlnstance. This pointer is 
then used by the Querylnterface methods of S1's external interfaces (IBasic and IPrint) to route interface re- 

10 quests to the enclosing multitype object. When an S1 interface is requested from the enclosing multitype ob- 
ject the method Querylnterface of the controlling lUnknown of the enclosing multitype object invokes the meth- 
od S1::Querylnterface, which returns a pointer to the appropriate instance of the interface IBasic, the interface 
IPrint, or the interface lUnknown and increments the S1 object's reference counting appropriately. (The mech- 
anism used by the enclosing multitype object to invoke S1::Querylnterface is discussed in detail below.) 

15 One skilled in the art would recognize that many alternatives exist for passing to an aggregatable object 

a pointer to the controlling lUnknown interface of an enclosing multitype object. For example, instead of passing 
the pointer at creation time, a method can be defined specifically for passing this pointer. Using this embodi- 
ment, an object can, once aggregated, be later unaggregated, or an object could later be aggregated into a 
different enclosing object. 

20 To understand how Code Table 8 interacts with a multitype object as depicted in Figures 7A-7C. it is helpful 

to see the calling sequence when client requests are made. Code Tattle 9 shows the pseudocode sequence 
of calls corresponding to Figure 7C when a client application requests the IBasic interface when the client has 
a pointer to the multitype object MTO. 

25 

Code Table 9 
MTO:: Querylnterface (IIDJBasic. ppv) 

which finds an aggregated object that supports tiie IBasic interface 
SI:: lUnknown : : Querylnterface (IID_lBasic. ppv) 
which returns pointer to the B interfoce 

In the first call (MTO::Querylnterface), MTO determines from its lists of aggregated interfaces which object's 
35 Querylnterface method to invoke and then invokes it in the second call (S1::IUnknown::Querylnterface). 

Code Table 10 shows how the pseudocode sequence of calls varies if the client application has a pointer 
to one of the enclosed object's interfaces (such as the IPrint interface of S1 ) instead of a pointer to the enclosing 
multitype object. 

40 

Codg Tabic 10 

P::Queryinterface (IID_lBasic, ppv) 

which forwards the call to the enclosing object 

MTO:: lUnknown:: Querylnterface (IID_IBasic, ppv) 
// m_puiikOuter points to MTO:: lUnknown 
which finds an aggregated object that supports the IBasic interface 
SI:: lUnknown:: Querylnterface (TID^IBasic, ppv) 
which returns pointer to the B interface 

50 

Code Table 1 0 demonstrates how aggregation will automatically forward requests to the enclosing object in 
order to access other Interfaces within the aggregate. In this case, the Querylnterface function of the enclosed 
object forwards the request to the enclosing object's (MTO's) Querylnterface method. Then, the MTO::Quer- 
55 yinterfaoe method functions as In Code Table 9. 

The 82 object that Implements the I Database Interface is analogous to the 81 object as described above. 
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Code Table 11 

void CrcatcInstanceMTO (lUnknown *punkOuter. REFIID iid, void **ppv) 
{ [Unknown *punk; 

MTO::CreateInstancc (punkOuter, &punk); 

pimk->QucTy Interface (iid, ppv); 

punk->Relea5e 0; 

) 

class IMultitype: public lUnloiown 

{ virtual HRESULT AddObject (ULONG list. BOOLEAN headoflist, 

lUnknown *punkobj) = 0; 
virtual HRESULT Addlntcrfacc (REFIID iid. ULONG list, BOOLEAN headoQist. 

void *pv) = 0; 

virtual HRESULT AddRule (REFIID iid, IRule ♦prule) 0; 

virtual HRESULT Enum (ULONG i. REFOD iid, ULONG list, BOOLEAN headoflist, 

void •*ppv) = 0; 

} 

class MTO: public FUnknown 
{ 

public: 

static void CreateInstanoe(IUnknown *punkOuter, lUnknown **ppunk) 
{ MTO "pMTO = new MTO(punkOuter); 

pMTO->QoeryInterface(lID_IUnknown, ppunk);} 

private: 

void MTO(IUnknown *punkOuter): m_MT(this) 
{ if (punkOuter == NULL) 

m_punkOuter = this; 

else 

ra_punkOuter = punkOuter,} 

class MT: public IMultitype 
{ 

public: 

void MT(MTO *pMTO) {m_pMTO = pMTO} 

virtual boolean CJuerylnterface (REFIID iid, void ♦•ppv) 

{ return m_pMTO->m_punkOutcr->Qucrylnterface(iid, ppv);} 

virtual void AddRefQ 

{ m_pMTO->m_punkOuter->AddRefO;} 

virtual void ReleaseQ 

{ m_pMTO->m_punkOutcr->Release();} 

virtual boolean AddObject (ULONG list, BOOLEAN headoflist, 
[Unknown ^punkobj) 
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{ item *pitem; 

pitem = new (item); 
pite]n->iid = ITDUnknown; 
5 pitem->pabj = punkobj; 

pitem->pncxt - null; 
pitein->pprev = null; 
switch (list) { 
caseNORMAL^LIST: 

10 if ... if headoflist = = true, insert as first item in normal list» 

// otherwise insert as last item; 
case DEFAULT_LIST: 

// ... if headoflist = = true, insert as first item in default list, 
// otherwise insert as last item; 
t5 case OVERRIDE_LIST: 

// ... if headoflist = = true, insert as fu^t item in override list, 
// otherwise insert as last item; 
defiuilt: 

// ... insert at head of normal list; 

20 } 
} 

virtual boolean Addlnterface (REFIID iid, ULONG list, BOOLEAN headoflist, 
void *pv) 

{ 

pitem->iid = iid; 
pitem->pobj = pv; 

// same code as for AddObject method except that list item points to 
li the particular interface and not to the lUnknown interface 
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} 

\\ other methods of IMultitype . . . 

private: 

MTO ♦m_pMTO; 

}; 

friend MT; 
MT m_MT; 

public: 

virtual boolean Querylnterface(REFIID iid, void **ppv) 
{ boolean done = TRUE; 

item *pitem; 

switch (iid) { 
case IlD_IMultiType: 

•ppv = &m_MT; 

mjpunkOuter->AddRef(); 

break; 
case IID_IUnknown: 

*ppv = this; 

AddRefO; 

break; 

default: 

// search through the override list for the ftfst matching interface 
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done = FALSE; 

pitem = m_povemde_itemhead; 

while ((done = = FALSE) && (pitem->pnext != null)) { 
switch (pitem->iid) { 
case lID^IUnknown: 

if (pitera->pobj->QueryInterface(iid, ppv) = = TRUE) 

done = TRUE; 
else pitem = pitcm->pnext; 
break; 
default 

if (pitem->iid = - iid) { 
ppv = pitem->pobj; 
done = TRUE; 

} 

else pitem - pitem->pnext; 

» 

// search through the nonnal list for the first matching interface 

// if not yet found 

if (done = - FALSE) { 

pitem - m_pnormail_itemhead; 

while ((done = FALSE) && (pitem->pnext != null)) { 
. . . // same code as for override list 

} 

// search through die defoult list for the first matching interface 
// if not yet found 
if(done = = FALSE) { 

pitem = m_pdefault_itemhead; 

while ((done - ^ FALSE) && (pitem->pnext != null)) { 
. . . // same code as for override list 

} 

break; 

} 

return done; 

} 

virtual void AddRefl[) { m_refcount++;} 

virtual void ReleaseQ {if (~m_refcount = = 0) delete this;} 

private: 

lUnknown • m_punkOuter; 

int m_refcount, m_occurrence; 

struct item { 

REFIID iid; 
void *pobj; 
item *pnext; 
item ♦pprev}; 

item *m_pnormal_itemhead = null, *m_pnormal_itemtail = null, 
*mjxlefauit_itemhead = null, *m_pdefault_itemtail = null, 
♦m_poverride_itcnihead = null, *m_poverride itemtail = null; 

}; 

Code Table 11 Is C++ pseudocode for a preferred class definition of a multitype object which can be used 
to dynamically aggregate interfaces. The class MTO implements an instance of the IMuititype interface and 
the controlling lUnknown interface for the multitype object. 

The global function Create! nstanceMTO creates an instance of an object of class MTO. A client invokes 
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this function to instantiate an object of class MTO. Using this function, a client can instantiate an object of dass 
MTO without having access to the MTO class definition at connpile time or run time. The function Createln- 
stanceMTO is passed a pointer to the controlling lUnknown interface (punkOuter) when the instantiated MTO 
object is aggregated within another object. The function invokes the method MTO::Createlnstance passing 

5 along the parameter punkOuter. 

The method MTO::Createlnstance Instantiates an MTO object and returns a pointer (ppunk) to the lUn- 
known interface of the MTO object This interface can then be used by the function Create! nstanceMTO to 
return the Interface actually requested by the client application. The method MTO:: Create Instance uses the 
operator new to instantiate the MTO object During instantiation, the constructor MTO::MTO is Invoked and 

10 passed the value of the parameter punkOuter. 

The constructor MTO:: MTO initializes the data members m_MT and m_punkOuter. During instantiation of 
the data member m_MT of class MT, the constructor MT::MT is Invoked and passed the this pointer for the 
MTO object (In C++, the this pointer points to the object instance itself.) The constructor MT::MT then sets a 
local variable pointing back to the MTO class. The constructor MTO::MTO is passed the parameter punkOuter. 

15 If the value of punkOuter is null, the constructor MTO;;MTO sets the data member m_punkOuter to point to 
the newly instantiated MTO object. If. on the other hand, punkOuter is non-null, for example. If the object is 
aggregated as part of a larger aggregation, the constructor MTO:: MTO sets the data member m_punkOuter 
to the value of the parameter punkOuter. That is, data member m_punkOuter points to the value of the con- 
trol ling lUnknown interface of the aggregate when the MTO object is enclosed and points to the lUnknown in- 

20 terface of the MTO object when the MTO object is not enclosed. 

The IMultitype interface implemented by the MTO object contains four methods AddObJect, Addlnterface, 
AddRuIe, and Enum. The method AddObject is responsible for adding an object to be enclosed within the mul- 
titype object (all of the object's interfaces are made accessible). It is discussed with reference to Figure 9. The 
method Addlnterface is responsible for adding a single interface instance to the multitype object. The method 

25 Addlnterface is discussed in conjunction with the method AddObJect The method AddRuIe enables a client 
application to specify a combining rule used to determine which combination of objects to query or interfaces 
to return when a client application requests a particular interface Identifier. It is discussed In detail In conjunc- 
tion with rule objects. The method Enum is used by rule objects to enumerate over the various Interface lists 
maintained by the multitype object This method is discussed In detail in conjunction with rule objects. 

30 Figure 9 is a flow diagram of the method AddObject of the IMultitype interface implemented by a multitype 

object. Figure 9 corresponds to the code for AddObject shown in Code Table 1 1 . The method AddObject is used 
by a client application to dynamically add to a multitype object access to all of the interfaces of an object This 
method is passed a list indicator Indicating to which list to add the object, an Indication of whether the object 
should be added to the head or tail of the specified list, and a pointer to the lUnknown Interface of the object 

35 to aggregate. This method, along with the method Addlnterface, Implements structures for maintaining Infor- 
mation regarding the objects and interfaces enclosed by a multitype object 

One typical implementation uses three list structures composed of elements each pointing to an interface 
of an enclosed object When the method AddObject Is Invoked to enclose the entire object, a new element Is 
added to the specified list structure; the new element points to the lUnknown interface of the enclosed object 

40 This lUnknown interface can then be used to access the component Interfaces of the enclosed object If, on 
the other hand, the method Addlnterface is Invoked to enclose a single Interface of an object, then a new list 
element is added to the specified list structure; the new element points to the single interface to allow direct 
access to it In a typical Implementation, each list element is indexed by an interface Identifier, points to an 
interface of an enclosed object, and points to the next element in the list. Since clients can add to either the 

45 head or tail of a list, a doubly linked list can be used to increase the efficiency. 

In the method invocation, a dient application specifies on which list the application wants to add the spe- 
cified interface or object. A "normal" list is used when the dIent application wants to simply add interfaces or 
objects to the aggregation. An "override" list and a "default" list are used when the dient application wants to 
add Interfaces whose methods will be invoked at a different time than those on the normal list. In a typical 

50 implementation, upon requestfor a particular Interface, the method Querylnterface of the controlling lUnknown 
of the multitype object will return the requested Interface searching first through the ovenride list, second 
through the normal list and third through the default list. One skilled In the art would recognize that many other 
Implementations and search strategies are possibly including varying the number of list structures, changing 
the search order, and changing the determination of what constitutes matching a requested interface. In a pre- 
ss ferred embodiment, as discussed in detail below, the client application may change the determination rules. 

The steps of Figure 9 illustrate how an element is added to the specified list In step 901. the method al- 
locates a new list item and, in step 902, initializes the item to point to the lUnknown interface of the object con- 
taining the interfaces the client application desires to aggregate and to contain the Interface identifier of the 
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item (to indicate the lUnknown interface). In step 903, the method determines whether the normal list has been 
specified. If so, the method continues at step 904, else it continues at step 907. In step 904, the method de- 
termines whether the client application wants to insert an element at the head of the normal list. If so, the meth- 
od continues at step 905, else it continues at step 906. In step 905. the method inserts the initialized element 

5 at the head of the normal list and returns. In step 906. the method Inserts the initialized element at the tail of 
the normal list and returns. Steps 907 through 914 operate analogously on the override and default lists. 

The method Addlnterface of the IMultitype Interface works similarly to the method AddObject. The primary 
difference Is that, instead of an added list element pointing to the specified lUnknown interface of the object 
to be enclosed, the added list element points to a specified interface and indicates the passed Interface klen- 

10 tif ler. In this manner, a single interface of an object can be aggregated without exposing other interfaces. 

Returning to Code Table 11, the methods Querylnterface, AddRef. and Release of the IMultitype interface 
(the Inherited lUnknown interface) forward requests to the lUnknown interface of the parent object that imple- 
ments this IMultitype interface (MTO). 

The controlling lUnknown interface implemented by the MTO object contains the methods Querylnterface, 

15 AddRef. and Release. The methods AddRef and Release implement reference counting of themultitype object. 
When the reference count Is zero, the MTO object is deleted. 

Figure 10 is a flow diagram of the method Querylnterface of the controlling lUnknown interface for a mul- 
tltype object. Figure 10 corresponds to the code for Querylnterface shown in Code Table 11 . The method Quer- 
ylnterface locates a requested interface using knowledge of its own implementation and information from the 

20 aggregated interface lists. The method takes an input parameter which is the requested interface identifier 
and outputs a pointer to the requested interface. In steps 1001-1004, the method determines whether the re- 
quested interface is one implemented by the multitype object itself. Otherwise, in steps 1005-1014. the method 
searches each enclosed object or interface until it finds the requested interface. 

In step 1001, the method determines whether the requested interface identifier is equivalent to IID_IMul- 

25 titype, and If it is, continues at step 1 002, else continues at step 1 003. In step 1 002, the method sets the output 
parameter to point to the instance of IMultitype implemented by the object MTO, and returns. In step 1003, 
the method determines whether the requested interface identifier is equivalent to 1 1 DJ Unknown and, if it is, 
continues at step 1004, else it continues at step 1005. In step 1004, the method sets the output parameter to 
the this pointer, which is the instance of lUnknown implemented by the multitype object, and returns. 

30 In steps 1005 through 1014, the method loops over the three lists searching for the first list element that 

points to an Interface matching the requested interface. When this interface Is found, it is returned In the para- 
meter ppv and the method returns a successful status. One skilled In the art would recognize that this imple- 
mentation is one example of many types of searches that can be used, in step 1005, a temporary list indicator 
is set to the next list from the set of lists implemented by a multitype object In a preferred embodiment, this 

35 set of lists Includes an override, a normal, and a default list. In step 1006, the method sets a temporary variable 
pitem to point to the front of the current list In step 1007, the method determines whether it has exhausted all 
of the elements in the current list and has still not found a matching interface. If the method has reached the 
end of the current list, then the method continues at step 1008, else It continues at step 1009. In step 1008, If 
the method determines that more lists are available to be searched, then the method continues t)ack at step 

40 1005 to begin searching a new list Otherwise, the method returns an unsuccessful status since no matching 
Interface was found. In step 1009, the method determines whether the current list element pointed to by the 
temporary variable pitem, points to an lUnknown interface, and if it does continues at step 1010, else it con- 
tinues at step 1013. (If the current list element points to an lUnknown Interface, then the object corresponding 
to the interface needs to be further queried for a matching interface.) In step 1010, the method calls the method 

45 Querylnterface of the lUnknown interface pointed to by the current list element In step 1 0il , the method de- 
termines whether the requested interface identifier was found and. If not, continues at step 1012, else returns. 
If the requested interface identifier was found, then the Querylnterface call would have already set the return 
parameter ppv to point to the requested interface. In that case, the method returns a successful status. Other- 
wise, In step 1012, the method Increments the current list element pointer (pitem) to point to the next element 

so in the list and continues at step 1007 to search through the current list structure. In step 1013, the method 
compares the requested Interface Identifier with the Interface klentif Ication field of the current list element and. 
If they are the same, continues at step 1014, else continues at step 1012 with the search. In step 1014, the 
method sets the return parameter ppv to point to the requested interface (pointed to by the current list element) 
and returns a successful status. 

55 Figure 11 is a block diagram showing the data structure layout of a multitype object corresponding to Fig- 

ure 70, after the I Basic, IPrint and IDatabase interfaces have been dynamically aggregated using the method 
AddObject The data structure layout comprises instance data 1101. virtual function tables 1104 and 1105, 
methods 1107 through 1115, and instances of currently enclosed (aggregated objects). The instance data 1101 
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contains a pointer to tlie virtual function table for tlie controlling lUnknown interface, data member m_MT which 
is an instance of dass MT (an Implementation of the IMultitype interface), data member mj:>unkOuter which 
points to the lUnknown interface of the MTO object, and data member m_pnonmaI_itemhead which points to 
the head of the normal list of currently added interfaces. As depicted, the list currently contains two elennents. 

5 List element 1102 points to an instance of an SI object 801-823 (as defined in Figure 8) and list element 1103 
points to an instance of an S2 object 1106. Although not shown, the multiple object also contains pointers to 
a default list and an override list, which are empty. 

When the enclosed SI object is instantiated, its data member S1::m__punkOuter is initialized to point to 
the lUnknown interface of the MTO object. Similarly, when the enclosed 82 object is instantiated, its data mem- 

10 ber S2::m__punkOuter is initialized to point to the lUnknown interface of the MTO object. This task is accom- 
plished, as previously discussed, by passing a pointer to MTO in the CreatelnstanceXX function (where XX is 
SI or S2). 



Code Table 12 

MTO *pMTO; 
IMultiType •myj>MT; 
FUnknown *pSpreadSheet, *pDataBase; 
CreatelnstanceMTO (NULL, lIDJUnknowii, pMTO); 
CreatelnstanceSl ft)MTO, UD IUnknown, pSpreadSheet); 
Crea:eInstanceS2 (pMTO, [ID_nJiikiiown, pDataBase); 
pMTO->Qucrylnterfece (UD_Multitype. my_pMT); 

my _pMT->Ad<10bject (IIDJSpreadSheet, NORMAL_LIST, true, pSpreadSheet) 

my_pMT->AddObject (IIDJDataBase, NORMAL LIST, true, pDataBasc); 

// Some later time, some other client can invoke the database capability of a spreadsheet object 
30 pSpreadSheet -> QueiyInterface(UD_IDataBase, ppv); 
ppv->DataO; 



Code Table 12 contains pseudocode for the preferred list of steps for dynamically aggregating a set of In- 
35 terfaces. This example corresponds to adding the interfaces for IBasic, IPrint, and IDatat>ase as shown in Fig- 
ure 7C using the method AddObject to add all of the interfaces of an object. First, a new multitype object Is 
allocated using the function CreatelnstanceMTO. Using this function, the lUnknown interface is retrieved for 
the newly Instantiated multitype object. This interface is passed to the 81 and S2 objects when they are in- 
stantiated to allow them to access the enclosing multitype object. At some point, an instance of the 81 object 
40 is created, passing it the pointer to the multitype object. Also, an instance of the S2 database object is created, 
passing It a pointer to the multitype object After these instances of SI and S2 have been created, the IMultitype 
interface is retrieved from the multitype object This interface will be used to dynamically add the spreadsheet 
and database Interfaces to the multitype object Next, the method AddObject of the IMultitype interface of the 
multitype object is invoked to aggregate the 81 and S2 objects into the multitype object Once these objects 
45 have been enclosed in the multitype object, a dient can use any interface of the multitype object or any of its 
enclosed objects to access any other Interface within the aggregate object Code Table 12 shows an example 
of retrieving the database Interface using the basic spreadsheet object (SI) and then invoking the data method 
of this IDatabase interface. 

50 
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CodcTablgl3 

class IMultitype: public lUnknown 

{ virtual HRESULT AddObject (ULONG list, BOOLEAN headoOist, 

lUnknown ^pimkobj) = 0; 
virtual HRESULT Addlirterfece (REFUD iid, ULONG list. BOOLEAN headoflist, 

void *pv) = 0; 

virtual HRESULT AddRule CREFIID iid, IRule *pmlc) = 0; 

virtual HRESULT Enum (ULONG i. REFOD iid, ULONG list, BOOLEAN headoflist, 

void **ppv) = 0; 

} 

class IRule: public lUnknown 

{ virtual HRESULT Init (IMultitype *pMTO) = 0; 

) 

class MTO: public lUnknown 
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{ 

public: 

static void Createiii5tance(IUnknown *punkOuter, lUnknown **ppunk) 
{ MTO •pMTO = new MTO(punkOuter); 

pMTO->QueryInterface(IIDJUnkiiown, ppunk);} 

private: 

void MTO(IUiiknown *punkOuter) : m_MT(this) 
{ if (punkOuter = NULL) 

m_pimkOuter = this; 

else 

in_pimkOuter = punkOuter, 
pQI = new(MyQl); // make a Querylnterface default rule 

pQI->QueTyInterface(IID_IRule, pnilc); 
m_MT->AddRule(IIDJUnknown, prule); 

> 

class MT: public IMultitype 
{ 

public: 

void MT(MTO ♦pMTO) {m_pMTO - pMTO} 

virtual HRESULT Querylnteiface (REFHD iid, void **ppv) 
{ return m j>MTO->m_puiikOuter->QueryInterfacc(iid, ppv);} 

virtual void AddRef() 

{ m_pMTO->m_pufikOuter->AddRefO;} 

virtual void Release<) 

{ m_pMTO->m_puiikOuter->ReleaseO;} 

virtual HRESULT AddObject (ULONG list, BOOLEAN headoflist, 
[Unknown *punkobj) 

{ item *pitcm; 

pitem = new (item); 
pitem->iid = IIDIUnknown; 
pitem->pohj = punkobj; 
pitem->pnext = null 
pitem->pprev - null; 
switch (list) ( 
case NORMAL_LIST: 

// ... if headoflist = ~ true, insert as first item in normal list, 
// otherwise insert as last item; 
case DEFAULT_L1ST: 

// ... if headoflist = = true, insert as first item in default list, 
// otherwise insert as last item; 
case OVERRIDE_LIST: 

// ... if headoflist = true, insert as first item in override list, 
// otherwise insert as last item; 
default: 

// ... insert at head of normal list; 

} 

} 

virtual HRESULT Addlnterface (REFIID iid, ULONG list, BOOLEAN headoflist. 
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15 



20 



void *pv) 

pitein->iid = iid; 
pitem->pobj = pv; 

// same code as for AddObject method except that list item points to 
// the particular interface and not to the lUnknown interface 



virtuaJ HRESULT AddRule (REFIID iid, IRuIe •prule) 

// this method adds a rule object to the list of mles in the muhitype object 

{ nileitem *pnileitem; 

pruieitem = new(ruleitem): 
pruleitem->iid= iid; 
pruleitem->pruie — prule; 
pnileitcm->pncxt = null; 
prule item->pprev = null; 

// insert in the rule list -- one way to do this is to insert the rule as last item 
// so Querylnterface is always first 



} 



prule-> Init(m_pMTO); // tell the rule about the multitype object 



virtual HRESULT Enum (ULONG i, REFIID iid, ULONG list, BOOLEAN headoflist, 
void **ppv) 

// this method returns the i'th occurrence of the element corresponding to the 
// specified iid in the specified list bcgirming with the head or tail of the list 
{ int counter = 0; 

item *pitem = null; 

ruleitem *pruleitem = null; 

boolean done = FALSE; 

switch (list) { 

35 case NORMAL_LlST: 

if (headoflist) { 

pitem = m_pMTO->ni_pnonnal_itemhead; 
while ((!done) && (pitem ! = null)) { 

// for each item in the list, compare either the pobj field if the 
40 U item points to an interface that has been added or query 

// interface the object to see if the interface exists if the entire 
// object has been added 
switch (pitem->iid) { 
case IID_IUnknown: 

4b if ((pitcm->pobj->QueryInterface(iid, ppv) = = TRUE) 

&& 

(counter = = i)) done TRUE; 
else pitem^item->pnext; 
break; 

50 default: 

if ((pitem->iid = = iid) && (counter = = i)) { 
done = TRUE; 
ppv = pitcm->pobj; 
} else pitem = pitem-> pnext; 
55 break; 
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else { // ... start from tail and work backwards using 
5 // pitcm = pitcm->pprcv; 

}; 

break; 
case DEFAULT_LIST: 

// works the same as the nDimal list except uses the defauh list 
,0 break; 

case OVERRIDE_LlST: 

works the same as the normal list except uses the override Ibt 
break; 
case RULE_LIST: 
if(headoflist) { 

pruleitem - m_pMTO->m_pruIe_itemhead; 
done = FALSE; 

while ((!done) && (pruleitem ! = null)) { 
if prulcitem->iid = = iid { 

ppv = pruleitem->pruie; 
done = TRUE; 
} else pruleitem = pruleitem->pnext; } 
} else { // ... start from tail and work backwards using 
// pruleitem = pruleitem->pprev; 

}; 

25 break; 

default: 

// use the same steps as for the normal list starting from the head 

} 

30 } 

private: 

MTO *m_pMTO; 
} ; // end of class definition for MT object 
35 friend MT; 

MT m_MT; 

public: 

virtual HRESULT QueryInterface(REFnD iid, void **ppv) 
^ { IRule *prule; 

ruleitem *pruleitmem; 

boolean done = TRUE, foundrule = FALSE; 

switch (iid) { 

case lIDJMultiType: 
^ *ppv = &m_MT; 

m_punkOuter->AddRefO; 
break; 
case nD_IUnknown: 
♦ppv = this; 
AddRefO; 

^ break; 

default: 

done = FALSE; 

// search through the rule list for the first matching [Unknown interne 
// and invoke it as the selection rule to access the combining rule for the 

65 
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// requested interface 
pruleitem = m_pnile_itemhead; 

while ((foundrule = ^ FALSE) && (pruleitem ! = null)) { 
if pnileitem->iid = = IID_IUnknown { 

prule = pruleitem->prule; 

foundrule = TRUE; 
} else pruleitem = prule itera->pnext; 

} 

if (foundrule) { // get and call its Queiy Interface method 
prule-> QueryInterfacB(IID_IUnknown, pselect); 
done = pselert-> Querylnter&ce(iid, ppv); 



) 

else { 



15 



25 



ppv)) 



} 

break: 



} 

return done; 



} 



// fmd the combining rule on the rule list and return it if it exists 
// this code is the default selection rule if one is not provided 
pruleitem = m_prule_itemhead; 
foundrule = FALSE; 

while ((foundrule = = FALSE) && (pruleitem ! - null)) { 
if pfuleitem->iid = = iid { 

pniie = pruleitcm->prulc; 
foundrule = TRUE; 
} else pruleitem = pruleitem->pnext; 

} 

if (foundrule) { // find the requested interface and retum it 

prule-> Querylnterfacc(iid, ppv); 
else // no combining rule exists so just return 1st interface found 

done = FALSE; 

// search through all lists for the first matching interface 
if ((m_MT->Enum(l, iid. OVERRIDE_LIST, true, ppv)) 

= ■= FALSE) {done = TRUE } ; 
else if ((m_MT->Enum(l, iid, NORMAL_LIST, true, ppv)) 

= = TRUE) { done = TRUE }; 
else if ((m_MT->Enum(l, iid, DEFAULT_LIST, true, 

= = TRUE) { done = TRUE }; 



virtual void AddRefQ { m_refcount-M-; } 

virtual void ReleaseO {if (--m refcount — 0) delete this;} 



private: 



lUnknown 
int 



*m_punkOuter; 
m_refcount; 



50 



struct item { 

REFIID iid; 
void *pobj; 
item *pnext; 
item *pprev } ; 



item *m_pnormal_itemhead = null, •m_pnormal_itemtail = null. 
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*mj3default_itemhead = null. *m_pdefeult_itemtai1 « null 
*in_povcmde_itemhead = nuU. *m_poveiTide_itemtail = null; 

stnia ruleitem { 

REFIID iid; 
IRuIe *prule 
ruleitem *pnext 
ruleitem *pprcv }; 

ruleitem *m_pnile_itemhcad = null, •m_prule_itemtail null; 

} ; // end of class definition for MTO object 

class MyQI: public [Unknown 

{ 

private: 

void MyQI: m R(thi3) {any other initialization code } 

class R: public IRule 
{ 

public: 

void R(MyQI *pMyQl) {m_pMyQI = pMyQI) } 

// ... lUnknown methods are also implemented here which call the controlling 
// lUnknown methods for the enclosing object (public methods shown below) 

virtual HRESULT Init (IMultitype* pIVITO) {m_pMyQI->m_pMTO = pMTO} 

private: 

MyQI *m_pMyQ[; 
} ; //end of class R definition 

friend R; 

R m^R; 

int m_refcount; 
IMultitype *m_pMTO; 

public: 

virtual HRESULT Querylntcrface (REFIID iid, void **ppv) 
{ IRuIe ♦prule; 

boolean done =» TRUE, foundmie = FALSE; 

switch (iid) { 

case IIDIRule: 

*ppv » & m_R; 
AddRef(); 
break; 
case IID_IUnknown: 
•ppv = this; 
AddRef(); 
break; 

default: // this is the same as code for our default rule for lUnknown 
// that knows how to search the lists of an MTO object 
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foundrule = m_pMTO->Enum( I , iid, RULE_LIST» true, pnile); 

if (foundmle) // return the combining rule for the 

5 requested IID 

{pnile-> Querylnterfece(iid» ppv);) 
else { // no combining rule exists so just return ist interface found 
done FALSE; 

// search through all lists for the first matching interface 
if ((m_pMTO->Enum(l, iid. OVERRIDE_LIST, true, ppv)) 

= = TRUE) {done = TRUE }; 
else if ((m_pMTO->Enum(I, lid, NORMAL LIST, true, 

ppv)) = = TRUE) f done = TRUE }; 
else if ((mj>MTO->lsnum(l, iid, DEFAULT__LIST, true. 

ppv)) = = TRUE) { done - TRUE }; 

15 J. 

break; 

}; 

return done; 

} 

20 

virtual void AddRefQ { m_refcount-H-;} 

virtual void ReleaseQ {if C-m_refcoum = 0) delete this;) 

25 y- 



Code Table 13 contains C++ pseudocode for a preferred class definition for a multitype object that has 
been enhanced to support a list of rule objects. Recall that these rule objects can either contain combining 

30 rules for connbining requested interfaces ofannultitype object or a selection rule for selecting a rule object (con- 
taining a combining rule) from the list of rule objects. Each rule object implements an instance of the {Rules 
interface for hooking the rule object into a multitype object Each rule object also implements an instance of 
the interface for which the rule object is providing a combining rule. For example, to coordinate printing all of 
the enclosed aggregated objects, a rule object that implements a combining rule for the IPrint interface can 

35 be provided. Such a rule object contains an Implementation of the IRules interface and an implementation of 
the IPrint interface. This specific example is discussed further below with reference to Code Table 14. 

Code Table 13 also shows C++ pseudocode for a preferred class definition for a rule object that contains 
a selection rule for selecting rule objects from a list of rule objects. To simplify the example, the rule provided 
by this rule object is similar to the default code used by a multitype object to access rule objects from the list 

40 of rule objects (as defined by MTO::Query Interface). However, one skilled in the art would recognize that this 
selecting rule object could implement any rule for accessing rule objects. 

As shown In Code Table 1 3, a multitype object implements two interfaces, IMultitype and lUnknown. These 
Interfaces are essentially the same as those described in Code Table 11, except, as noted In the following de- 
scription. The fundamental change from Code Table 11 shown In Code Table 13 is that the method Queryln- 

45 terface of the controlling lUnknown (MTO::Querylnterface) no longer searches through the three lists of en- 
closed interfaces for a matching interface according to a fixed set of rules. (The fixed rules shown in Figure 
11 amount to returning the first found interface from among the override, normal, and default lists in that order.) 
Instead, once It determines that an interface Is requested that Is not implemented by the MTO object itself, 
MTO::Querylnterface defers the request to a rule object corresponding to the requested Interface, if one exists 

50 on the MTO object's list of rule objects. The found rule object is then responsible for either providing an im- 
plementation of the requested Interface or returning an Interface from the MTO object's three lists of aggre- 
gated Interfaces. Thus, a client application can change the behavior of method Querylnterface of the controlling 
lUnknown of the aggregated object by providing its own rule objects for retrieving or combining particular in- 
terfaces. These rule objects can be implemented independent of the implementation of the multitype object 

55 because they can use a public enumeration method provided by the multitype object to access the enclosed 
Interface and rule lists. In addition, a client application can change the selection rule used by MTO::Queryln- 
terface for finding the rule object conresponding to the requested Interface by providing a rule object for the 
lUnknown Interface. 
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In addition to the methods AddObJect and Addlnterface already described with reference to Code Table 
11, the class MTO provides two methods for handling rule objects: AddRule and Enum. The method AddRule 
performs similarly to Addlnterface. The method AddRule creates a new list item for the list of rule objects and 
initializes this item to point to the interface identifier and the IRule Interface of the rule object passed as Input 

5 parameters. The method then inserts the new list item In the list of rule objects and invokes the method I nit 
of the IRule interface pointed to by the new list item in order to give the rule object access back to the MTO 
object. Such access is used by the rule object to invoke the method Enum to access the other lists of interfaces. 

As shown, the method AddRule adds a new rule object to the end of the list of rule objects. In addition, 
the Querylnterface methods using the list of rule objects assume that there is only one rule object per interface 

10 identifier (or that rather the first one found is valid). Therefore, some error checking or order control is preferably 
implemented. One skilled in the art will recognize that, like the other enclosed interface lists, a new rule object 
could be inserted into either the head or the tail of the list Also, the method AddRule could be changed to pass 
In a parameter indicating where to add the new rule object similar to AddObJect and Addlnterface. Alternatively, 
the rule list Items could be implemented identically to the other list items and the method Addlnterface could 

15 be used to insert rule objects into the list of rule objects. One skilled in the art would recognize that many other 
techniques are possible and that, in an abstract sense, rule objects are also dynamically aggregated objects. 

The class MTO provides the method Enum for searching and retrieving a specified interface. Rule objects 
for combining rules can use this method to retrieve interfaces from the three aggregated interface lists. In ad- 
dition, rule objects for selecting combining rules can use this method to retrieve rule object IRule interfaces 

20 from the list of rule objects. As shown, the method Enum returns the i'th occunrence of an interface matching 
a requested interface identifier from a specified list. The method starts from the head or tail of the list as spe- 
cified in the invocation. In an alternate emtx)diment. the enumerator is implemented as four separate methods: 
one per list enumerated. 

For the normal, default, and override lists, the method Enum examines each list item from the specified 
25 list until it finds the requested interface identifier or it exhausts the items in the list. During examination, If a 
list item points to an entire object, then the method Enum invokes the method Querylnterface of the object 
pointed to by the list item to potentially retrieve and return the requested interface. Otherwise, If the list item 
points to an interface other than lUnknown. the Interface identifier pointed to by the list item is compared di- 
rectly to the interface identifier requested, and. if they match, the interface pointed to by the list item is returned. 
30 If a list item fails to produce a matching interface, then the method continues to search the remainder of the 
specified list 

The method Enum provides slightly different behavior for searching and retrieving from the list of rule ob- 
jects. Instead of returning the requested interface identifier, the method uses the interface identifier to find a 
matching item on the list of rule objects and then returns a pointer to the IRule interface of the rule object cor- 

35 responding to the requested Interface kJentlfler. 

In Code Table 13, the method Querylnterface of the MTO enclosing object has been modified to support 
the list of rule objects. The method first determines whether the interface requested in an input parameter is 
implemented by the MTO object Itself. If so, the method returns this Interface. Otherwise, the method retrieves 
and invokes a selecting rule if one exists on the listof rule objects. Finally, if no selecting rule exists, the method 

40 Querylnterface provides default selection code. 

A rule object provides a selecting rule If It Is added to the list of rule objects under the lUnknown Interface 
Identifier. Preferably, this interface identifier is reserved for this purpose. In one emt>odiment. the first such 
rule object found is retrieved as the selecting rule. If it exists, the retrieved selecting rule is responsible for 
searching for and retrieving a combining rule or. if no combining rule exists, searching for and retrieving an 

45 interface from the three lists of aggregated interfaces. The retrieved selecting rule Is invoked by querying the 
rule object corresponding to the lUnknown interface identifier for its lUnknown interface (using the IRule in- 
terface) and then invoking the method Querylnterface of this retrieved lUnknown interface. Note that the re- 
trieved lUnknown interface is the controlling lUnknown interface of the rule object. 

If no selecting rule exists, the method MTO::Querylnterface provides default selection code. This default 

50 selection code returns a combining rule for the requested interface if one exists, or returns the first matching 
interface found from the normal, override, and default lists in that order. (The default selection code when no 
combination rule exists behaves similarly to the method MTO::Querylnterface.) The rule object Implementing 
the combining rule is then responsible for either providing an implementation of the requested interface or re- 
turning an interface from the MTO object's three lists of aggregated interfaces. 

55 As an example, Code Table 1 3 illustrates an implementation for a rule object that provides a selection rule 

for selecting rule objects from the list of rule objects. Class MyQI is a rule object implementing an IRule inter- 
face and an lUnknown interface. For ease of understanding, class MyQI is shown as a non-aggregatable object 
The IRule interface provides a method Init, for maintaining a pointer to the enclosing multitype object (MTO) 
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containing this rule object This MTO pointer can be later used to access the nnethod Enum of the IMultitype 
Interface in order to access the aggregated interfaces and objects. The method Init is invoked by AddRule when 
a rule object is added to the list of rule objects. The lUnknown interface provides an implementation of Quer- 
ylnterface that knows how to select a combining rule object from the list of rule objects. As shown, 

5 MyQI::Querylnterface provides the identical functionality to that provided by MTO::Query Interface. However, 
the implementation differs in that MyQI::Querylnterface uses the method Enum to find a combining rule in- 
stead of searching the list itself. One skilled in the art would recognize that MTO::Querylnterface could have 
been implemented identically. 

An example of using a MyQI rule object is shown in the method MTO::MTO. When the multitype object Is 

10 instantiated, the constructor MTO::MTO is invoked. This constructor creates a new rule object for the lUnknown 
interface using the MyQI dass definition and then adds this rule object to the list of rule objects using the meth- 
od AddRule. One skilled in the art will recognize that adding a rule object implementing a selection rule can 
really be done at any time. 

class [Print: public lUnknown 

{ virtual boolean Print (void **ppobj) - 0; 

20 ) 

class myPrintRulc: public lUnknown 
private: 

25 

void myPrintRule: m_R(this), m_P(this) {/•any other initialization code*/ } 

class R: public IRule 
{ 

30 public: 

void R(myPrintRule ♦pmyPrintRule) {m_pMyRule = pmyPrintRuie) ) 

// ... lUnknown methods are also implemented here which call the controlling 
// lUoknown methods for the enclosing object (public methods shown below) 

35 

virtual HRESULT Init (IMultitype *pMTO) {m_pMyRuIe-^m_pMTO = pMTO} 

private: 

myPrintRule * m_pMy Rule ; 
} ; //end of class R definition 

40 

friend R; 

R m_R; 

class P: public IPrint 

46 { 

public: 

void P(myPrintRule *prayPrintRule) {m_pMyRule = pmyPrintRule) } 

// .„ lUnknown methods are also implemented here which call the controlling 
// [Unknown methods for the enclosing object (public methods shown below) 

virtual void Print (void * pobj) 

// call each aggregated object print routine on each list in order of overriding 
// and then normal list and only call print routine from default list if no print 
// routine exists on normal list 
{ IID_IMuUitype ♦pJMT; 

lIDJPrint •pjprint; 

int ij; 
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p_iMT = m_pMyRule->m_pMTO; 

for (i - 1; p__iMT->Enum(i, IIDJPrint, OVERRIDE_UST, true, &pjprint); 

i++) p_iprint->Print(pobj); ~ 
for (j 1; p_iMT->EnumG, nDJPrint, NORMAL_LIST, true, &p_iprint); 

j-H-) p_print->Prmt(pobj); 
if ((i= =1) && (j= = 1 ) && (p_iMT->Enum( I JIDJPrint, DEFAULT_LIST, 

mie, &p_prmt))) p_print->Print (pobj); 

); 



20 



25 



public: 



} 

private: 

myPrintRuIe *ra_pMyRule; 

}; 

fiiend P; 

P in_P; 

int m_refcount; 
IMultitype •m_pMTO; 



virtual HRESULT QueryInterface(REFIID iid. void •*ppv) 
{ ret =« TRUE; 

switch (iid) { 



case IID_IPrint: 

♦ppv = &in_P; 

AddRef(); 

break; 

30 case IIDJRuIe: 

•ppv = & m_R; 

AddRefO; 

break; 
case IID IUnknown: 
35 ♦ppv = this; 

AddRefO; 

break; 

} 

40 return ret; 

) 

virtual void AddRefQ { m_refcount4-f;} 
4Q virtual void ReleaseQ {if (-m refcount = 0) delete this;} 



50 Code Table 14 shows C++ pseudocode for an example of using a multitype object and a rule object to pro- 

vide overriding behavior for a set of aggregated objects or Interfaces. Typically, when a set of objects of dif- 
ferent types Is aggregated, each object provides Its own print method which knows how to print the object Code 
Table 14 shows C++ pseudocode for a preferred class definition of a rule object that provides a combination 
rule for the IPrInt interface. The provided IPrInt interface includes a method Print, which invokes the print meth- 

55 od of each enclosed object or interface in an enclosing multltyp>e object. 

Class myPrintRule provides an Implementation for at least two interfaces, as do all rule objects: in this 
case, IRule and IPrint. The IRule interface provided by class myPrintRule is functionally identically to dass 
MyQI. already discussed with reference to Code Table 13. The IPrint interface simply provides a combining 
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rule that enumerates through the three lists of aggregated objects in a multitype object searching for other 
IPrint interfaces and invoking their Print routines when found. As discussed with reference to Code Table 13, 
after this rule object is added to the list of rule objects in a multitype object, the method Querylnterface of the 
controlling lUnknown of the multitype object will preferably return a pointer to this combining rule IPrint inter- 
5 face when a client application invokes Querylnterface requesting IIDJPrint on the aggregated object As a re- 
sult, when the client application invokes the method Print, the method Print implemented by this rule object 
will instead by invoked to ensure that the aggregated object prints its components correctly. 



CodeTahlelS 

pPrintRule = new(myPrintRule); // make a IPrint interface combining rule 

pPrintRule->QueryInterfece(IlD JRuIe, pnile); 
p_MTO->QueTyInterface(IIDJMuItitype, p_MT); 

p_MT->AddRuIe(IID_lPrini, pru le); // add it to the Multitype object 



Code Table 15 shows a C+-t- pseudocode sequence of calls that installs the rule object defined In Code 

20 Table 14. First, a new instance of the class myPrintRule rule object is created. Second, the I Rule interface of 
the new rule object is retrieved for later use. Third, after obtaining from somewhere a pointer to a multitype 
object (p_MTO), the IMultltype interface of the multitype object is retrieved. Finally, the method AddRule of 
this retrieved IMultitype interface is invoked passing it the interface identif ierfor the new rule object (IIDJPrint) 
and a pointer to the I Rule interface of the new rule object. 

25 In a preferred embodiment, an aggregated object is persistently stored using the same mechanism illu- 

strated for printing. Specifically, a multitype object provides a combination rule object for the IPersistFile in- 
terface or for any other interface responsible for saving and retrieving objects. (The IPersistFile Interface pro- 
vides methods for saving and loading objects.) In this manner, the multitype object is able to override the saving 
functionality of the enclosed objects and interfaces to ensure that the whole aggregated object Is saved. The 

30 combination rule preferably saves any data structures that the multitype object needs first and then invokes 
the method Save on each of the enclosed IPersistFile interfaces or objects. Thus, in order to participate in 
saving the aggregate object, a client program adds the IPersistFile interface of an object to be enclosed, or 
encloses the entire object. No separate storage is needed in a separate file: the multitype object can store its 
own data in an analogous manner to how object data is stored within a single file. 

35 In an alternate embodiment that implements only one list of aggregated interfaces or objects and rules 

(instead of three lists plus the list of rule objects), the multitype object needs no storage of its own. No storage 
aside from that used by the aggregated objects is necessary because the multitype object can recreate the 
single list by examining the ordering and indexing information of the aggregated objects in the hierarchical per- 
sistent storage structure. However, a multitype object that implements multiple interface lists typically needs 

40 to store information to distinguish which interface instances are pointed to by which list. 

The present embodiment of the current invention assumes that when the controlling IUnknown::Queryln- 
terface method invokes the Querylnterface methods of the enclosed objects such invocation is performed syn- 
chronously. That is, the enclosed object Querylnterface method returns before the controlling lUn- 
known::Querylnterface method invokes the next enclosed object Querylnterface method. In an alternate em- 

45 bodiment, the controlling lUnknown: :Query[nterface method calls the enclosed object Querylnterface meth- 
ods asynchronously, not waiting for their return. Instead, standard interprocess communication mechanisms 
are used to Inform the controlling routine when the enclosed object method has completed. Such an embodi- 
ment is useful in a networking or multiprocessor environment. 

A typical application of the present Invention for dynamic aggregation Is for a user to combine Instances 

so of objects into a more powerful object using a program that has been developed with knowledge of dynamic 
aggregation. For example, suppose, using the spreadsheet interface example presented In the background 
section, that a software vendor ships a spreadsheet product from which a user can create aggregatable spread- 
sheet objects that only support the IBasic Interface for basic manipulation of a spreadsheet (That Is, using 
this product, a user can create instances of the IBasic Interface, which are spreadsheet objects.) Further sup- 

55 pose that another software vendor ships a database product from which a user can create aggregatable da- 
tabase query objects. These aggregatable database query objects support the IDatabaseQuery interface, 
which for example includes a method DoQuery to run a query and a method Def IneQuery to enable a user a 
specify a query. When attached to other objects that can serve as input data, these database query objects 
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can be invoked to query the attached input data. Also suppose that resident on the computer system is a pro- 
gram, for example a file manager, that manages objects and that knows how to create multitype objects and 
aggregate other objects and interfaces together. To do this task, the file manager knows how to create a mul- 
titype object that provides an implementation of the IMultitype interface. 

5 Figure 12 is a pictorial representation of a spreadsheet object and a database query object, which can be 

aggregated together to create an attached database query object. To create a more powerful object that can 
perform a specified query on a specified database (the attached database query object 1205), the user first 
creates, using the spreadsheet product, an instance of a spreadsheet object 1201, which the user wants to 
use as Input data. Then, the user creates an instance of a database query object 1202 using the database 

10 product. The user then invokes the method Def IneQuery of the IDatabaseQuery interface by pressing the de- 
fine button 1204 and enters text for the database query using a database language; for example, the SQLIan- 
guage. Next, the user invokes the file manager 1208. Using the file manager, the user selects the spreadsheet 
object 1201 and the database query object 1202 and requests that the file manager 1208 aggregate them. 
The user might indicate this request, for example, by dragging and dropping the display representation of the 

15 spreadsheet object 1201 onto the data input port 1203 of the display representation of the database query ob- 
ject 1202. In response to the user's request, the file manager 1208 instantiates a new attached database query 
object 1205 by instantiating an enclosing multitype object and invoking the method IMultitype::AddObject for 
both the spreadsheet object 1201 and the database query object 1202. The file nrtanager 1208 also passes to 
both the spreadsheet object 1201 and the database query object 1202 a pointer to the controlling lUnknown 

20 interface of the newly instantiated multitype object. The user can then invoke the attached database query 
object by selecting the "Go" button 1206, to perform the specified query on the attached spreadsheet data. 

One skilled in the art would recognize that once an object is aggregated, it is subject to the rules of the 
enclosing object. Thus, the behavior of spreadsheet object 1201 and the database query object once enclosed 
may change. 

25 Figure 13 is a block diagram of an aggregated attached database query object. The aggregated object 

1304 corresponds to the attached database query object described with reference to Figure 12. The aggre- 
gated object 1304 comprises a multitype object 1301 , a spreadsheet object 1302, and a database query object 
1303. The multitype object 1301 is created, as described above, in response to the user request to aggregate 
spreadsheet object 1302 and database query object 1303. During the process of aggregation, the multitype 

30 object creates pointers 1 305 and 1306 to the aggregated objects and passes to the objects to be aggregated 
a pointer to the controlling lUnknown interface. Later, when the user presses the "Go" button (1206 In Figure 
12), the controlling lUnknown interface of the multitype object 1307 Is invoked to locate and invoke the method 
DoQuery of the IDatabaseQuery interface of the database query object 1303 using the above-described env 
bodiments. The method DoQuery can then query for and invoke a (known) desired method of the spreadsheet 

35 object 1302 by searching for a (known) desired Interface identifier of the spreadsheet object 1302 using the 
method Querylnterface. (To recall, the Invocation of the method Querylnterface will get forwarded to method 
Querylnterface of the controlling lUnknown 1307 the multitype object 1301, which will locate the desired in- 
terface If it exists.) Thus, the database query object 1303 Is able to Invoke the methods of the spreadsheet 
object 1302 without having access to the compile time definitions of the interfaces of the spreadsheet object 

40 1302 as long as it knows the name (and parameters) of the method and the interface identifier. 

Although the present Invention has been described In terms of a preferred embodiment, It Is not Intended 
that the invention be limited to this embodiment Modifications within the spirit of the invention will be apparent 
to those skilled in the art. The scope of the present Invention is defined by the claims which follow. 

46 

Claims 

1. A method In a computer system for adding an interface to an object, the Interface implemented by an object 
being able to be enclosed Into an enclosing object, the method comprising the steps of: 
50 creating an instance of the enclosing object, the enclosing object having an add Interface function 

member for adding an interface to the enclosing object and a query function member for retrieving a ref- 
erence to an added interface; 

creating an instance of an object to be enclosed within the enclosing object, passing a reference 
to the enclosing object, the object to t>e enclosed having an interface and having a query function nnember 
55 for retrieving a reference to the Interface; and 

invoking the add interface function member of the enclosing object, passing a reference to the ob- 
ject to be enclosed, thereby enclosing the object and adding the interface of the enclosed object to the 
enclosing object whereby when the query function member of the enclosing object is Invoked, the query 
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function member of the enclosing object returns a reference to the added interface of the enclosed object. 

The method of claim 1, wherein the invocation of the query function member of the enclosing object is 
performed asynchronously. 

The method of daim 1, wherein the invocation of the query function member of the enclosing object is 
performed synchronously. 

The method of claim 1 . wherein the enclosing object provides a default interface. 

The method of daim 1. wherein the enclosing abject provides an Interface that overrides the added in- 
terface of the endosed object 

The method of daim 1 , wherein the enclosing object has no knowledge of the interfaces exposed by the 
enclosed object. 

The nriethod of claim 1 , further comprising the steps of: 

creating an instance of a second object to be endosed within the enclosing object, whereby the 
second object is passed a reference to the enclosing object, the second object having an exposed inter- 
face; and 

invoking the add interface function member of the enclosing object, wherein the exposed interface 
of the second object is added to the endosing object, thereby endosing the second object, whereby when 
the query function member of the enclosed first object is invoked, the query function member of the en- 
closed first object returns a reference to the added exposed interface of the enclosed second object. 

The method of daim 7, wherein the exposed interface of the enclosed second object overrides an interface 
of the enclosed first object. 

The method of claim 7. wherein the exposed interface of the enclosed second object invokes an interface 
of the enclosed first object. 

The method of claim 7, wherein the exposed Interface of the enclosed second object is a default Interface. 

The method of claim 7, the enclosed first object containing a pointer to the endosing object, the second 
object having a query function member for retrieving a reference to the exposed interface of the second 
object, and further Induding the steps of: 

first, invoking the query function member of the endosed first object requesting an exposed inter- 
face of the second object; 

second, retrieving a reference to the query function member of the enclosing object through the 
pointer to the enclosing object contained by the endosed first object; 

third, invoking the query function member of the enclosing object, passing the requested interface; 

fourth, from the query function member of the enclosing object, invoking the query function mem- 
ber of the enclosed second object, passing the requested interface; and 

fifth, from the query function member of the enclosed second object, returning a reference to the 
requested interface. 

The method of daim 7, the endosing object having an add rule function member for adding rules for de- 
termining to which added interface to retrieve a reference, and further comprising the step of invoking 
the add rule function memberof the enclosing object to add a rule for determining to which added interface 
to retrieve a reference, whereby when the query function member of the enclosing object is invoked, the 
query function member determines from the added ruie to which added interface to return a reference. 

The method of claim 1, the computer system having a device for persistent storage, further including the 
steps of: 

after enclosing an object into the enclosing object, thereby creating an aggregate object, storing 
the aggregate object on the persistent storage device; and 

subsequently loading the stored aggregate object from the persistent storage device. 

A method In a computer system for changing the behavior of an object, the method comprising the steps 
of: 
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creating an instance of an enclosing object, the enclosing object having a query function member 
for retrieving a reference to an interface instance and an add rule function member for adding rules for 
determining to which interface Instance to retrieve a reference; 

adding a plurality of interface instances to the enclosing object; and 

invoking the add rule function member of the enclosing object to add a determination rule for de- 
termining to which interface instance to retrieve a reference. 

The method of claim 14, the method being language independent 

The method of claim 14. further including the step of invoking the query function member of the enclosing 
object to retrieve a reference to a requested interface, whereby the query function member of the enclos- 
ing object determines using the added rule to which Interface instance to return a reference. 

The method of claim 14, wherein the added determination rule combines the retrieval of a plurality of ref- 
erences to interface instances. 

Themethodof dalm 14, wherein the added determination rule Is implemented by a rule object and wherein 
the step of invoking the add rule function member further Includes the step of instantiating the rule object. 

The method of claim 14, further comprising the steps of: 

invoking the add rule function member of the enclosing object to add a second determination rule 
for determining to which interface instance to retrieve a reference; and 

creating a selecting rule for selecting which determinatnn rule to use for determining to which in- 
terface instance to retrieve a reference, whereby when the query function member of the enclosing object 
IS invoked, the query function memt>er uses the selecting rule to select between the first detenmination 
rule and the second determination rule, wherein the selected determination rule determines to which In- 
terface instance to retrieve a reference. 

A computer system for adding an interface to an object, the system comprising: 

an enclosing object having an add interface function member for adding an interface to the enclos- 
ing object and a query function member for retrieving a reference to an added interface; and 

an object to be enclosed with the enclosing object, the object to be enclosed having an interface 
and a query function member for retrieving a reference to the interface, wherein the object is enclosed 
and the interface added by invoking the add interface function member of the enclosing object passing 
it a reference to the object to be enclosed, and whereby when the query interface function member of the 
enclosing object is invoked after the object is enclosed, the query interface function member returns a 
reference to the added interface of the enclosed object. 
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